Re: [PHP-DEV] ze2 segfault #2

[Sterling Hughes]

Nevermind, I found the bug, and I have a fix that I'm testing right now.

-Sterling

On Fri, 2003-03-21 at 16:53, Sterling Hughes wrote:
> When running the following example through pres2 (apache 1.3.27), I get
> a segfault..  Sample pres2 file.
> 
> 
> Interfaces Suck
> They really do
> 
> 
> 
> interface2.php::
> 
>  interface ISerializable {
> function sleep();
> function wakeup();
> };
> 
> class Person implements ISerializable {
> public $name;
> 
> function sleep() {
> file_set_contents("serialized",
> serialize($this->name)
> );
> }
> 
> function wakeup() {
> $this->name = unserialize(
> file_get_contents("serialized")
> );
> }
> }
> 
> $p = new Person;
> if ($p instanceof ISerializable) {
> $p->wakeup();
> }
> echo "Previous Spy: {$p->name}\n";
> $superspies = array('James Bond',
> 'Sterling Hughes',
> 'Austin Powers');
> $p->name = $superspies[array_rand($superspies)];
> echo "New Spy: {$p->name}\n";
> 
> if ($p instanceof ISerializable) {
> $p->sleep();
> }
> ?>
> 
> -- 
> "Nothing is particularly hard if you divide it into small jobs." 
> - Henry Ford
-- 
"Programming today is a race between software engineers stirring to  
 build bigger and better idiot-proof programs, and the universe trying  
 to produce bigger and better idiots. So far, the universe is winning." 
- Unknown


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

[PHP-DEV] ze2 segfault #2

[Sterling Hughes]

When running the following example through pres2 (apache 1.3.27), I get
a segfault..  Sample pres2 file.


Interfaces Suck
They really do



interface2.php::

name)
);
}

function wakeup() {
$this->name = unserialize(
file_get_contents("serialized")
);
}
}

$p = new Person;
if ($p instanceof ISerializable) {
$p->wakeup();
}
echo "Previous Spy: {$p->name}\n";
$superspies = array('James Bond',
'Sterling Hughes',
'Austin Powers');
$p->name = $superspies[array_rand($superspies)];
echo "New Spy: {$p->name}\n";

if ($p instanceof ISerializable) {
$p->sleep();
}
?>

-- 
"Nothing is particularly hard if you divide it into small jobs." 
- Henry Ford


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

Re: [PHP-DEV] segfault with ze2/php5-cvs

[Sterling Hughes]

On Fri, 2003-03-21 at 15:12, Joey Smith wrote:
> Very nice.
> 
> What about:
> 
>class person {
>   var $name;
>   }
> 
>   $start = new person;
>   $start->name = 'Eve';
>   $new = $start->__clone();
> ?>
> 
> Does it come back with 'Call to a member function on a non-object'?
> 
> 

I get a segfault with that as well, same error. execute_data is
corrupted.

-Sterling

> On Fri, Mar 21, 2003 at 02:47:06PM -0500, Sterling Hughes wrote:
> >  > class sheep {
> > var $name;
> > }
> > 
> > $start = new sheep;
> > $start->name = "Dolly";
> > $new = $start->__clone();
> > $new->name = "Molly";
> > var_dump($start);
> > ?>
> > 
> > BOOM!
> > 
> > -Sterling
> > -- 
> > Good judgement comes from experience, and experience comes from 
> > bad judgement. 
> > - Fred Brooks
> > 
> > 
> > -- 
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
-- 
"The three most dangerous things in the world are a programmer  
 with a soldering iron, a hardware type with a program patch and  
 a user with an idea." 
- Unknown


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

[PHP-DEV] segfault with ze2/php5-cvs

[Sterling Hughes]

name = "Dolly";
$new = $start->__clone();
$new->name = "Molly";
var_dump($start);
?>

BOOM!

-Sterling
-- 
Good judgement comes from experience, and experience comes from 
bad judgement. 
- Fred Brooks


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

[PHP-DEV] Re: [PHP-CVS] curl multi

[Sterling Hughes]

On Mon, 2003-03-17 at 10:29, Wico de Leeuw wrote:
> sorry for writing to the wrong list should have been phpdev offcourse
> At 16:28 17-3-03 +0100, Wico de Leeuw wrote:
> >Hiya,
> >
> >If someone has some spare time could he look at curl_multi_info_read() i'd 
> >like to use (test) the curl_multi functions, but without the 
> >curl_multi_info_read it isn't really usefull (and when i look at the 
> >source i thing it's almost finished)
> >
> >P.S. when i test them i'll report back to you guys when i find things
> >
> >Greetz and tnx in advance
> >

It is still very useful, what would give you the idea it isn't?

-Sterling


> >Wico
> >
> >
> >--
> >PHP CVS Mailing List (http://www.php.net/)
> >To unsubscribe, visit: http://www.php.net/unsub.php
> >
-- 
"People can have the Model T in any colour -- so long as it's black." 
- Henry Ford


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

Re: [PHP-DEV] Moderate PHP-DEV

[Sterling Hughes]

On Wed, 2003-03-12 at 14:00, Weston Houghton wrote:
> This worries me somewhat. I do not have a CVS account. I do not 
> actively develop and contribute to the PHP sourcecode right now, 
> however my company uses php very very much. I would like to keep up to 
> date on what is happening with the development team and figuring out 
> what directions they are leaning and why. And if I want to contribute 
> code down the road, I would like to be able to.
> 
> So, I don't have a cvs account right now, and I don't need one, but if 
> it were required to be on the list, then I would not be able to be on 
> the list.
> 
> I'd appreciate not having that requirement myself.

You could be on a list of pre-allowed posters.  also note, this is only
a write requirement, reading is completely free.

-Sterling

> 
> Wes
> 
> 
> 
> On Wednesday, March 12, 2003, at 01:53  PM, Marcus Börger wrote:
> 
> >
> >> A couple thoughts
> >>
> >> Aside from renaming the php-dev list, we should remove the 'PHP and 
> >> Zend Engine internals lists' from the regular mailing list page, put 
> >> them in a 'developers' section (name isn't important) that describes 
> >> cvs access, dev email lists, how to build (ie. win32 libraries), etc.
> >
> > I guess this is the solution!
> >
> >> Then another item that might be considered if it is not already done, 
> >> allowing posts only from those that have cvs access.
> >
> > Hm, i don't know. I for one directly contacted rasmus as he was the 
> > developer mentioned in the sources
> > in which i found and corrected errors when i started working here. 
> > However i guess not all of us started
> > this way, did we?
> >
> >> A second conditional list of allowed posters can be added that are 
> >> people who do not have cvs access, but we want to allow to post.
> >
> > That would be a minimum requirenment
> >
> >> Otherwise, the list can be readable by all.
> >
> > Dito.
> >
> >> A post rejected message could tell them to try a different email 
> >> list, but if they really feel the email is for the dev list
> >
> > I already did this proposal but it was declined...
> >
> >> , send it to [EMAIL PROTECTED] and it will be reviewed by someone when they 
> >> get the time.
> >
> > Round robin list? Everyone in php-dev has to take care for some days?
> >
> > regards
> > marcus
> >
> >
> > -- 
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
-- 
"C makes it easy to shoot yourself in the foot; C++ makes it harder,  
 but when you do, it blows away your whole leg." 
- Bjarne Stroustrup


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

Re: [PHP-DEV] Moderate PHP-DEV

[Sterling Hughes]

On Wed, 2003-03-12 at 12:50, Sascha Schumann wrote:
> > Let's ask the mysql guys, they did change the name too. (I think that we
> > atleast agree that the noise is annoying, right?)
> 
> Not really.  Maybe I'm more used to skipping noise.
> 

*exactly* my point btw.  We skip noise, skip noise, skip noise, miss
important message, skip noise, skip noise. :)

-Sterling

> - Sascha
-- 
"Science is like sex: sometimes something useful comes out, 
but that is not the reason we are doing it." 
- Richard Feynman


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

Re: [PHP-DEV] Moderate PHP-DEV

[Sterling Hughes]

> > Then another item that might be considered if it is not already done,
> > allowing posts only from those that have cvs access.  A second
> > conditional list of allowed posters can be added that are people who do
> > not have cvs access, but we want to allow to post.  Otherwise, the list
> > can be readable by all.  A post rejected message could tell them to try
> > a different email list, but if they really feel the email is for the dev
> > list, send it to [EMAIL PROTECTED] and
> 
> This however sounds too restrictive to me.  I'm convinced
> that the main php development list should stay as open as
> possible.  The issue of a few misdirected emails should not
> serve as an excuse for closing down the main development
> list.  We should not become an ivory tower.
> 

Yes, because getting a cvs account is just *s* hard.  We are more an
Ivory tower now, than we would be under the proposed systems. 
Currently, unless someone points me elsewhere I only read messages from
PHP core devs.  I don't have the time or the energy to filter through
the noise.  Most other developers do this, being overburdened with the
crap ratio makes me put up a wall.  If this list was moderated, ie, less
noise, more thoughtful comments, most people would probably be able to
read a lot more messages.

An Ivory tower implies a system dictated by an external force (wealth,
for example), not one dictated by merit.  The roundtable is reserved to
those who have earned it.

> > it will be reviewed by someone when they get the time.
> 
> This manual review effectively implies censorship which is
> undesirable in an open environment.  I doubt it would serve
> the PHP community in any way.
> 

It doesn't.  They are free to send the mail to whomever they like, even
put up a website with their ideas.  They are not censured, they are
restricted.  In what country can you walk onto the floor of the congress
(parliament) without sponsorship?  Entirely open infrastructures are
great when the community is small/growing, but when the community is
this size, we need to be pragmatic and not lose the forest for the
trees.

-Sterling

> - Sascha
-- 
"Programming today is a race between software engineers stirring to  
 build bigger and better idiot-proof programs, and the universe trying  
 to produce bigger and better idiots. So far, the universe is winning." 
- Unknown


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

Re: [PHP-DEV] Moderate PHP-DEV

[Sterling Hughes]

On Wed, 2003-03-12 at 12:01, Derick Rethans wrote:
> On Wed, 12 Mar 2003, Jani Taskinen wrote:
> 
> > 
> > Of about 20 emails today, 6 were posted to wrong mailing
> > list. And one of those generated a 5 email thread about not
> > posting to wrong mailing list. (counting this one :)
> > 
> > So I suggest we finally make this list MODERATED.
> 
> +1

+1.  

People who say that important messages will get lost: they already do. 
Many people can't hear over the din.  I'm more worried about the 25% of
developer mail that gets lost than the 1% of useful user mail that might
get lost.

-Sterling

> 
> Derick
> 
> -- 
> "my other box is your windows PC"
> -
>  Derick Rethans http://derickrethans.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
-- 
"Science is like sex: sometimes something useful comes out, 
but that is not the reason we are doing it." 
- Richard Feynman


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

Re: [PHP-DEV] Doing something with an each opcode as zend_execute() handles it

[Sterling Hughes]

> On Wednesday, March 05, 2003 5:35 PM, Sterling Hughes wrote:
> 
> >> Just before zend_execute()/execute() handles each opcode in its big
> >> switch() statement, I'd like to be able to call a function and pass
> >> it the opcode (or other information from the opline.
> >>
> >> Is the best approach to reset zend_execute to a new function in the
> >> PHP_MINIT_FUNCTION() (and restore the saved value in
> >> PHP_MSHUTDOWN_FUNCTION)? This new function would mostly be a copy of
> >> execute() in zend_execute.c with my addtional function call tossed
> >> in.
> >>
> >> What's the difference between zend_execute() and
> >> zend_execute_internal()?
> >>
> >
> > Well, I have a feeling what you are talking about is sub-optimal,
> > what do you want to do?
> 
> Essentially, I want to be able to produce a sort of serialized
> representation of the opcodes, but as they are executed, not all in one big
> chunk after they are compiled.
> 
> This isn't for any actually useful production code, just some
> debugging/messing around/exploring engine internals.
>
I would suggest you take a look at Ze2's execution architecture, it
should allow you to do this.

-Sterling

> David

-- 
"Reductionists like to take things apart.  The rest of us are
 just trying to get it together."
- Larry Wall, Programming Perl, 3rd Edition

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

Re: [PHP-DEV] Doing something with an each opcode as zend_execute() handles it

[Sterling Hughes]

> Just before zend_execute()/execute() handles each opcode in its big switch()
> statement, I'd like to be able to call a function and pass it the opcode (or
> other information from the opline.
> 
> Is the best approach to reset zend_execute to a new function in the
> PHP_MINIT_FUNCTION() (and restore the saved value in
> PHP_MSHUTDOWN_FUNCTION)? This new function would mostly be a copy of
> execute() in zend_execute.c with my addtional function call tossed in.
> 
> What's the difference between zend_execute() and zend_execute_internal()?
> 

Well, I have a feeling what you are talking about is sub-optimal, what
do you want to do?

-Sterling

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

-- 
"Reductionists like to take things apart.  The rest of us are
 just trying to get it together."
- Larry Wall, Programming Perl, 3rd Edition

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

Re: [PHP-DEV] Tie'ing variables

[Sterling Hughes]

On Sun, 2003-03-02 at 14:22, Shane Caraveo wrote:
> So I'm not clear on how I am should expect this to work.  A simple script:
> 
> error_reporting(2047);
> print_r($_ENV);
> 
> is now completely broken unless you turn on register_long_arrays.  If 
> that is expected behaviour, register_long_arrays must be on by default.
> 

Of course its not the expected behavior.  The functionality isn't fully
integrated/mature yet. :)

-Sterling

> Shane
> 
> 
> Zeev Suraski wrote:
> > I wanted to do this for some time, but until recently, it wasn't very 
> > feasible, because the order of registration could be designated by the 
> > user (gpc_order, variables_order, etc.).  Now that register_globals is 
> > off by default, and that we have the auto-globals, it's much more feasible.
> > 
> > I implemented this optimization in CVS, so far only for $_ENV and 
> > $_SERVER.  This alone pushed nearly-empty-page req/sec pages from about 
> > 285 to about 400 on my Windows box.  I'll look into fixing the other 
> > ones later.
> > 
> > Pre-requisites for this optimization to kick in:
> > 1.  register_globals being off
> > 2.  register_long_arrays (HTTP_*_VARS) being off
> > 
> > If you want to benchmark w/ vs. w/o, you can disable the optimization by 
> > initializing cb to 0 in php_startup_auto_globals() and 
> > jit_initialization to 0 in php_hash_environment(), both in 
> > main/php_variables.c.
> > 
> > Zeev
> > 
> > At 18:26 01/03/2003, Sterling Hughes wrote:
> > 
> >> Hi,
> >>
> >> Analyzing PHP's routines a bit, it seems that the slowest part of a
> >> "generic" request is populating the special arrays, $_ENV, $_GET, etc.
> >>
> >> I was wondering if it might be possible to "tie" these arrays to a
> >> function (if you don't understand that, look at Perl for a definition).
> >> One could populate them as an overloaded object, and then array accesses
> >> would work - I guess.  But I would prefer a cleaner mechanism.
> >>
> >> This would prevent a costly overhead for elements that don't really need
> >> to be there, and yield only a slight performance cost when accessing
> >> overloaded elements in these arrays.
> >>
> >> -Sterling
> >>
> >> -- 
> >> "The computer programmer is a creator of universes for which he
> >>  alone is responsible. Universes of virtually unlimited complexity
> >>  can be created in the form of computer programs."
> >> - Joseph Weizenbaum
> >>
> >>
> >> -- 
> >> PHP Development Mailing List <http://www.php.net/>
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> > 
> > 
-- 
"Nothing is particularly hard if you divide it into small jobs." 
- Henry Ford


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

Re: [PHP-DEV] Tie'ing variables

[Sterling Hughes]

On Sat, 2003-03-01 at 13:09, Faisal Nasim wrote:
> At 10:26 PM 3/1/2003, Marcus Börger wrote:
> > At 18:11 01.03.2003, Derick Rethans wrote:
> > > On Sat, 1 Mar 2003, Sterling Hughes wrote:
> > > 
> > > > Analyzing PHP's routines a bit, it seems that the slowest part
> > > of a
> > > > "generic" request is populating the special arrays, $_ENV,
> > > $_GET, etc.
> > > >
> > > > I was wondering if it might be possible to "tie" these arrays to
> > > a
> > > > function (if you don't understand that, look at Perl for a
> > > definition).
> > > > One could populate them as an overloaded object, and then array
> > > accesses
> > > > would work - I guess.  But I would prefer a cleaner mechanism.
> > > 
> > > Why not just populate them when you need them? IE, if you access
> > > $_GET['foo'] it processes the GET data until it has processed upto
> > > foo
> > > in the data itself(and of course it adds the other ones that are
> > > before 'foo' in the GET data to the array too). With this you
> > > never
> > > process more data then you really need...
> > 
> > And for a quick start it would be enogh to simply initialize these
> > vars upon
> > first access. If we can do this the rest might be easy -> "devide
> > and conquer"!
> 
> Just had a thought. Wouldn't it be possible for some intermediate
> included script to change the data which is parsed and stored into
> $_GET (and family) upon first request?
> 

err, it already is possible for an included scripting to change the
value of $_GET variables.  I don't see what request order matters,
variables are parsed per-request.

-Sterling


> Faisal
-- 
"Science is like sex: sometimes something useful comes out, 
but that is not the reason we are doing it." 
- Richard Feynman


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

Re: [PHP-DEV] Tie'ing variables

[Sterling Hughes]

On Sat, 2003-03-01 at 12:11, Derick Rethans wrote:
> On Sat, 1 Mar 2003, Sterling Hughes wrote:
> 
> > Analyzing PHP's routines a bit, it seems that the slowest part of a
> > "generic" request is populating the special arrays, $_ENV, $_GET, etc.
> > 
> > I was wondering if it might be possible to "tie" these arrays to a
> > function (if you don't understand that, look at Perl for a definition). 
> > One could populate them as an overloaded object, and then array accesses
> > would work - I guess.  But I would prefer a cleaner mechanism.
> 
> Why not just populate them when you need them? IE, if you access 
> $_GET['foo'] it processes the GET data until it has processed upto foo 
> in the data itself(and of course it adds the other ones that are 
> before 'foo' in the GET data to the array too). With this you never 
> process more data then you really need...
> 

Err, that's exactly what I said. :)  That's what tieing a variable is,
it controls access to variables via a function.  An internal
implementation would probably look something like that (on the cgi sapi
at least, on the apache sapi it wouldn't).

-Sterling

> Derick
-- 
"A business that makes nothing but money is a poor kind of business." 
- Henry Ford


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

Re: [PHP-DEV] Tie'ing variables

[Sterling Hughes]

On Sat, 2003-03-01 at 11:51, George Schlossnagle wrote:
> Having this sort of functionaility in general would be great.  I know 
> you can affect this with objects via overload, but it is useful for 
> scalars and arrays and streams as well.  It is pretty 'magical' though.
> 

Yeah - but just to be clear.  I'd be perfectly happy with this just
existing on an extension level.

-Sterling

PS:  I'd be for a user level api as well, but I don't have the energy to
fight that battle. :)

> -- 
> "Nothing is particularly hard if you divide it into small jobs." 
> - Henry Ford


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

[PHP-DEV] Tie'ing variables

[Sterling Hughes]

Hi,

Analyzing PHP's routines a bit, it seems that the slowest part of a
"generic" request is populating the special arrays, $_ENV, $_GET, etc.

I was wondering if it might be possible to "tie" these arrays to a
function (if you don't understand that, look at Perl for a definition). 
One could populate them as an overloaded object, and then array accesses
would work - I guess.  But I would prefer a cleaner mechanism.

This would prevent a costly overhead for elements that don't really need
to be there, and yield only a slight performance cost when accessing
overloaded elements in these arrays.

-Sterling

-- 
"The computer programmer is a creator of universes for which he  
 alone is responsible. Universes of virtually unlimited complexity  
 can be created in the form of computer programs." 
- Joseph Weizenbaum


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

Re: [PHP-DEV] Mono & PHP

[Sterling Hughes]

On Wed, 2003-02-05 at 17:26, George Schlossnagle wrote:
> On Wednesday, February 5, 2003, at 05:22  PM, Stig S. Bakken wrote:
> 
> > On Mon, 3 Feb 2003, Sebastian Bergmann wrote:
> >
> >> Sterling Hughes wrote:
> >>> I'll be adding it into PECL in a little bit
> >>
> >>   Why PECL and not add it to ext/rpc?
> >
> > ext/rpc should be able to load "rpc backend" modules, or PECL is the 
> > only
> > sensible place to put it (especially when it's experimental!).  We 
> > really
> > don't want to mix java, mono, xmlrpc, soap and whatnot into a single
> > package.
> 
> Nor (as cool as it may be), is there a reason it should be in the 
> 'core' (extension-wise) of php.

Once stable, i think that could be up to a debate :-)

For one, if this ends up being fast enough, I think it should definitely
be in the engine core.  Accessing .NET/CIL will allow PHP to integrate
and leverage quite a few external technologies, and will allow it to
directly access *any* C library function call directly, or with a few
line wrapper.

But its a debate for when its more stable.

-Sterling

-- 
"The computer programmer is a creator of universes for which he  
 alone is responsible. Universes of virtually unlimited complexity  
 can be created in the form of computer programs." 
- Joseph Weizenbaum


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

Re: [PHP-DEV] OO in PHP5 (was "zend_API.c" on php-dev)

[Sterling Hughes]

On Mon, 2003-02-03 at 15:41, George Schlossnagle wrote:
> On Monday, February 3, 2003, at 03:20  PM, Harald Radi wrote:
> 
> > Hrmfpsd,
> >
> > while commiting a new functions the parameter parsing API i appearently
> > brought up a discussion about the meaning of life and stuff :) As 
> > asked by
> > Andi i'm bringing the discussion to php5-dev with a short summary:
> >
> > andrei's point:
> > extensions should stick to either functional or oo API
> > PEAR wrappers can be provided
> >
> > my point:
> > extensions should expose both APIs (if desired)
> > can be done by aliasing functions to class methods -> no duplicate c 
> > code
> > when called as function -> print warning
> > when called as method -> throw exception
> >
> > What do you guys think of this ?
> 
> I like your method.  I've implemented it for a coupe extensions (except 
> for the exception vs. error thing), and I found it to be quite 
> manageable and very little work.

Needless to say (it was implemented in adt quite awhile ago), I think
this is the better way.  In any event, I don't see the downside to
adding this api:  Whomever wants to use it can take advantage of it,
those who think its stupid, don't need to use it.

-Sterling

-- 
"Programming today is a race between software engineers stirring to  
 build bigger and better idiot-proof programs, and the universe trying  
 to produce bigger and better idiots. So far, the universe is winning." 
- Unknown


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

Re: [PHP-DEV] Mono & PHP

[Sterling Hughes]

On Mon, 2003-02-03 at 03:51, Alan Knowles wrote:
> I'm having fun with it :)
> /usr/src/php/php5/ext/sockets/php_sockets.h:89: conflicting types for 
> `SOCKET'
> /usr/include/mono/io-layer/uglify.h:38: previous declaration of `SOCKET'
> 
> also had a bit of trouble with mono's exception.h including config.h 
> (which wasnt installed into the bulid stuff)
> 
> (hacked mono's header for the time being)
> 
> not sure if that's an old version of mono though..
> 

Ahh, should have mentioned that.  I hacked php_sockets.h, just change
the typedef to a #define.

-Sterling

> Regards
> Alan
> 
> Sterling Hughes wrote:
> 
> >I spent a little time this weekend implementing an extension that allows
> >PHP to load .NET classes on the Unix environment - 100% open source, by
> >leveraging the mono library(*).  For more information, view the README
> >file in the distribution by downloading the file
> >http://www.edwardbear.org/php_mono_0_1.tar.gz.
> >
> >Its PHP5 only, as that's what I've switched to for all new development.
> >Hi Ho.
> >
> > >$Console = new Mono('System.Console');
> >$Console->WriteLine('Hello World, PHP is .NET ready!');
> >?>
> >
> >- Sterling "No More Extensions Needed" Hughes
> >
> >(*) Mono is much more than library, of course.  But it links to/uses the
> >mono library.
> >
> >PS:  I'll be adding it into PECL in a little bit, I want to finish the
> >type proxying code.  I'd also like to add all of the object and method
> >caching.
> >
> >PPS: If anyone has suggestions for a better way of doing type proxying
> >than what's described in the README, please let me know.
> >
> >  
> >
-- 
"Whether you think you can or think you can't -- you are right." 
- Henry Ford


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

[PHP-DEV] Mono & PHP

[Sterling Hughes]

I spent a little time this weekend implementing an extension that allows
PHP to load .NET classes on the Unix environment - 100% open source, by
leveraging the mono library(*).  For more information, view the README
file in the distribution by downloading the file
http://www.edwardbear.org/php_mono_0_1.tar.gz.

Its PHP5 only, as that's what I've switched to for all new development.
Hi Ho.

WriteLine('Hello World, PHP is .NET ready!');
?>

- Sterling "No More Extensions Needed" Hughes

(*) Mono is much more than library, of course.  But it links to/uses the
mono library.

PS:  I'll be adding it into PECL in a little bit, I want to finish the
type proxying code.  I'd also like to add all of the object and method
caching.

PPS: If anyone has suggestions for a better way of doing type proxying
than what's described in the README, please let me know.

-- 
"First they ignore you, then they laugh at you,  
 then they fight you, then you win."  
- Gandhi


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

Re: [PHP-DEV] Practical question

[Sterling Hughes]

On Sat, 2003-01-25 at 15:52, Miham KEREKES wrote:
> Hi,
> 
> Well, I know, this list is not for aiding users developing _with_ PHP
> but for developing _the_ PHP, but I think, this is the best place for
> this question -- correct me if I'm wrong.
> 

you're wrong.  ask this question on [EMAIL PROTECTED]

-Sterling
-- 
"Programming today is a race between software engineers stirring to  
 build bigger and better idiot-proof programs, and the universe trying  
 to produce bigger and better idiots. So far, the universe is winning." 
- Unknown


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

[PHP-DEV] PHP and XML mailing list

[Sterling Hughes]

A mailing list for discussing the future of PHP and XML development has
been created.  You can subscribe by sending a message to
[EMAIL PROTECTED] (normal ezmlm commands apply).  This
mailing list is _only_ intended for actual php extension and api
development, user support questions should remain on
[EMAIL PROTECTED]

-Sterling

-- 
"Nothing is particularly hard if you divide it into small jobs." 
- Henry Ford


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

[PHP-DEV] ADT alpha 1

[Sterling Hughes]

Hi,

ADT alpha 1 is available!  ADT is a PHP extension that provides a
collection of Abstract Data Types (ADT), including trees, graphs,
queues, heaps, sets and stacks.  

You can find more information about adt, and installing alpha 1, at
http://www.php.net/~sterling/adt/.  

-Sterling

-- 
"The three most dangerous things in the world are a programmer  
 with a soldering iron, a hardware type with a program patch and  
 a user with an idea." 
- Unknown

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

RE: [PHP-DEV] Feature Request: Auto Include a Function

[Sterling Hughes]

Hi Brian,

thanks for your comments, I'll be working on this, expect an
implementation sometime in the near future, and structure your code
accordingly!

-Sterling

On Mon, 2003-01-13 at 17:01, Brian T. Allen wrote:
> > From: Andrew Brampton [mailto:[EMAIL PROTECTED]] 
> > Sent: Monday, January 13, 2003 2:16 PM
> > Subject: Re: [PHP-DEV] Feature Request: Auto Include a Function
> > 
> > 
> > I'm not a PHP Developer but I see a few problems with this.
> 
> I'm not a PHP Developer either, but I use it 12 hours a day in my work.
> 
> 
> > Since a PHP script is re-evaluated/"compiled" on each 
> > execution it would
> > mean PHP would have to look through all your .php files for 
> > this file. This
> > could be very time consuming, espically since it has to do it every
> > execution.
> 
> If a hash file were used it would only have to "search" for the function
> once, and even then only in the functions directory (like the include
> directory, but specifically for functions).  After that the order would
> be:
> 
> 1) Execute the function
> 2) If the function doesn't exist check the hash file and include it
> 3) If it's not in the hash file search for it, include it, then hash it
> 4) If it can't be found issue an error message
> 
> If there we're no subdirectories there would be no more overhead than
> for a file_exists() call.
> 
> 
> > Also what happens if you spell a function wrong, OR it finds 
> > 2 functions
> > with the same name in different .php files.
> 
> If you spell a function wrong it isn't going to work either way, and I
> think it's a good idea to have your function names be unique within a
> give site.
> 
> 
> > I don't think its got any real advantage over the fact that 
> > it just lets you
> > be lazy. It wouldn't be any quicker in any way.
> 
> One mans laziness is another mans efficiency. If we were after 100%
> performance we'd all be programming in machine lanquage.  But that fact
> is I personally use PHP over other solutions because it's easier to
> develop in.
> 
> Given the chance I'll sacrifice a little (in this case very little)
> performance to speed up and simplify development.  At $50 an hour and 8
> hours per day, ~my~ CPU cycles are worth $8,000 per month.  I pay $100 a
> month for a server with the majority of CPU cycles going to waste.
> Personally I'd rather optimize the $8,000 rather than the $100.
> 
> Not everyone is in my shoes, but adding this won't effect them.  The
> little bit of overhead to automatically include functions is ONLY
> incurred if the function isn't included to begin with.  So existing
> scripts and programming styles won't be affected at all.
> 
> But I think it would simplify things a LOT on a big site with lots of
> functions.
> 
> > If this was a compilable language then sure it would of been 
> > nice, like C
> > does searching through .h files, but since its not I don't 
> > think its a good
> > idea.
> > 
> > Andrew
> 
> Thanks for the reply!
> 
> Brian
> 
> 
> > - Original Message -
> > From: "Brian T. Allen" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, January 13, 2003 8:21 PM
> > Subject: [PHP-DEV] Feature Request: Auto Include a Function
> > 
> > 
> > > Hi,
> > >
> > > Please accept my apologies in advance if this is not the 
> > correct place
> > > for this request.
> > >
> > > This may exist, but I haven't been able to find it, and I 
> > think it would
> > > be REALLY helpful and convenient.
> > >
> > > The idea is this:
> > >
> > > When you write a script and call a function:
> > >
> > >  > >
> > > $whatever = previously_uncalled_function("one","two");
> > >
> > > ?>
> > >
> > > PHP could automatically look for a file named
> > > "previously_uncalled_function" in your /include/functions/ 
> > (or whatever)
> > > directory.
> > >
> > > This would eliminate a LOT of include() and require() calls 
> > (or at least
> > > make them automatic) in a script.  The function would only 
> > get read in
> > > if it was used.  Functions could still be explicitly included or
> > > required as they currently are.
> > >
> > > I *think* the overhead would be about the same as the 
> > initial include()
> > > or require() call would have been.
> > >
> > > This would be very convenient.  When you create a new 
> > function you drop
> > > it in that directory (with a very specific, unique name, of 
> > course), and
> > > it can immediately be called anywhere in the site.  And, 
> > you only incur
> > > the disk IO to read it when its used for the first time in a script.
> > >
> > > The 3 things I want to avoid are:
> > >
> > > 1)  Explicitly including every function, every time it's needed.
> > > 2)  Disk IO of including a function when it's not needed.
> > > 3)  Taking the easy route and including a file with a bunch 
> > of functions
> > > when most won't get called.
> > >
> > > Does this already exist, or is this a good idea (if not, any reasons
> > > why)?  I personally would love to see it implemented if it isn't
> > > al

[PHP-DEV] php5 object model

[Sterling Hughes]

Hey,

ADT is the Abstract Data Type extension available on cvs.php.net, module
name "adt."  I'm nearing an alpha, but have one outstanding issue.  ADT
itself provides both a functional and an object oriented interface. The
following example shows the two ways you can use a stack.

Functional
--


Object Oriented
--
push($i);
}

var_dump($stack->pop());
$stack->destroy();
?>

ADT works fine with Zend Engine version 1, however, when using Zend
Engine 2, the code segfaults when registering a new object:

zend_hash_apply_with_argument (ht=0x0, apply_func=0x81117a0
, argument=0x0)
at /home/sterling/work/os/php/php5/Zend/zend_hash.c:702
702 HASH_PROTECT_RECURSION(ht);
(gdb) bt
#0  zend_hash_apply_with_argument (ht=0x0, apply_func=0x81117a0
, argument=0x0)
at /home/sterling/work/os/php/php5/Zend/zend_hash.c:702
#1  0x081196fa in _object_and_properties_init (arg=0x402c3a8c,
class_type=0x8171000, properties=0x0)
at /home/sterling/work/os/php/php5/Zend/zend_API.c:588
#2  0x0811971b in _object_init_ex (arg=0x402c3a8c, class_type=0x8171000)
at /home/sterling/work/os/php/php5/Zend/zend_API.c:610
#3  0x0806591c in adt_register_resource (tptr=0x81b67c0, le_id=15,
r_id=0x402c2d2c, obj=0x402c3a8c, cp=0x8171000, 
id=0x81b67d0) at
/home/sterling/work/os/php/php5/ext/adt/php_adt.c:127
#4  0x08067a5e in zif_adt_stack_new (ht=0, return_value=0x402c3aac,
this_ptr=0x402c3a8c, return_value_used=0)
at /home/sterling/work/os/php/php5/ext/adt/php_stack.c:53
#5  0x081276cc in zend_do_fcall_common_helper (execute_data=0xbfffd730,
op_array=0x402c21ac)
at /home/sterling/work/os/php/php5/Zend/zend_execute.c:2566
#6  0x0812426f in execute (op_array=0x402c21ac) at
/home/sterling/work/os/php/php5/Zend/zend_execute.c:1218
#7  0x081188f3 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/sterling/work/os/php/php5/Zend/zend.c:996
#8  0x080f57e8 in php_execute_script (primary_file=0xba10) at
/home/sterling/work/os/php/php5/main/main.c:1691
#9  0x0812c4ed in main (argc=2, argv=0xbaa4) at
/home/sterling/work/os/php/php5/sapi/cli/php_cli.c:753

The relevant code relating to this segfault is:

object_init_ex(obj, cp);

where obj is the zval * returned by getThis(), and cp represents a
zend_class_entry *, registered by the following code.

INIT_CLASS_ENTRY(stack_class_entry, "adt_stack",
stack_class_functions);
zend_register_internal_class(&stack_class_entry TSRMLS_CC);

and stack_class_entry is of type zend_class_entry.  cp is therefore a
pointer to the global stack_class_entry.  I'm running the non-threadsafe
version of php.

How can I make this code run with PHP 5?

-Sterling


-- 
"C makes it easy to shoot yourself in the foot; C++ makes it harder,  
 but when you do, it blows away your whole leg." 
- Bjarne Stroustrup

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

[PHP-DEV] [Fwd: 4.3.0 w/ Sablotron version check problem]

[Sterling Hughes]

-Forwarded Message-

> From: Lars Consume <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Luke Murphy <[EMAIL PROTECTED]>
> Subject: 4.3.0 w/ Sablotron version check problem
> Date: 08 Jan 2003 15:23:07 -0500
> 
> Dear Mr. Hughes,
> 
> Since 4.3.0 is a recent release, and because I haven't been able to 
> find any similar information on the Web or in any of the large PHP 
> forums, I am writing to you to notify you of a problem I'm having when 
> running the ./configure command against php 4.3.0 with the Sablotron 
> extensions. Namely, the configure script reports that I need Sablotron 
> v 0.96 or higher, when in fact I have just installed Sablotron v 0.97. 
> I have run ldconfig, and have checked the sablot-config file to make 
> sure there isn't a typo in there--sure enough it says "0.97". I'm 
> wondering if there's a bug in the configure information or in one of 
> the checks.
> 
> Here's my command line:
>   ./configure --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local 
> --disable-short-tags --with-config-file-path=/etc 
> --with-calendar=shared --with-curl=/usr/local --enable-exif 
> --enable-ftp --with-gd --with-jpeg-dir=/usr/local --enable-magic-quotes 
> --with-mcrypt=/usr/local --with-mhash=/usr/local --with-ming=/usr/local 
> --with-mysql --with-openssl --with-pear --with-pgsql 
> --with-png-dir=/usr/local --enable-sockets --with-t1lib=/usr/local 
> --enable-track-vars --enable-trans-sid --with-ttf --enable-wddx 
> --with-xml --enable-xslt --with-xslt-sablot --with_sablot_js 
> --with-zlib --with-zlib-dir=/usr/local
> 
> And here's my error output during config:
> checking for XSLT Sablotron backend... yes
> checking for libexpat dir for Sablotron XSL support... yes
> checking for iconv dir for Sablotron XSL support... yes
> checking for JavaScript for Sablotron XSL support... yes
> checking for Sablotron libraries in the default path... found in 
> /usr/local
> checking for sablot-config... found
> checking for Sablotron version... configure: error: Sablotron version 
> 0.96 or greater required.
> 
> The Machine is Red Hat Linux v 2.4.7-10
> 
> Please feel free to forward this e-mail to anyone who might be a more 
> appropriate recipient.
> 
> Thank you for your time.
> 
> Kristofer Widholm
-- 
"Reductionists like to take things apart.  The rest of us are 
 just trying to get it together." 
- Larry Wall, Programming Perl, 3rd Edition

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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Sterling Hughes]

> So code should be backwards compatible?  Very nice.
> 
> Any good links you could throw my way describing proposed changes?
>

never said that.  but constructors will be backwards compatible.

changes are available in the ZendEngine2 cvs repository.

-sterling

> Thanks guys.
> 
> John
> 
> Sterling Hughes said:
> >> On Monday, January 6, 2003, at 09:48  PM, Brian Moon wrote:
> >>
> >> >From what I understand, all OO code will have to be modified for
> >> PHP5. Constructors for example and no longer named the same as the
> >> class  name.
> >> >That alone means every class must be changed.  I don't recall anyone
> >> saying
> >> >it would be BC either, but I could be wrong.
> >>
> >> You're wrong.
> >>
> >> Of course, I could be too.
> >>
> > but you're not.  so its ok...
> >
> > :)
> >
> > -Sterling
> >
> >>
> >> --
> >> PHP Development Mailing List <http://www.php.net/>
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

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

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[Sterling Hughes]

> On Monday, January 6, 2003, at 09:48  PM, Brian Moon wrote:
> 
> >From what I understand, all OO code will have to be modified for PHP5.
> >Constructors for example and no longer named the same as the class 
> >name.
> >That alone means every class must be changed.  I don't recall anyone 
> >saying
> >it would be BC either, but I could be wrong.
> 
> You're wrong.
> 
> Of course, I could be too.
>
but you're not.  so its ok...

:)

-Sterling

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

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

Re: [PHP-DEV] ZEND_NUM_ARGS()

[Sterling Hughes]

> Probably but it looks like that filetype(null); for example under windows
> will return type directory...
> 
> So it looks an important bug too.
> 

Its about as much of a bug as passing filetype(null) isn't a bug.

-Sterling

"Ask a stupid question, get a stupid answer."
- Father Benedict Groeschel

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

Re: [PHP-DEV] ZEND_NUM_ARGS()

[Sterling Hughes]

> Hello,
> 
> After seeing the bug #21410, I just found that function_name(null)
> will make ZEND_NUM_ARGS()
> returning 1. I really think that null should be ignored or something...
>Actually with filetype(null), it transforms null in a string and try
> to stat "null" which is a bit stupid...
> 
> Any comment?
>

Hrmm, while this is a very interesting idea, unfortunately it would be bad
for backwards compatibality issues.

-Sterling

"Stupid is as stupid does."
- Forrest Gump

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

Re: [PHP-DEV] memleak in string.c?

[Sterling Hughes]

> /home/ari/php-4.3.0RC4/ext/standard/string.c(1350) :  Freeing 0x08D0D354 
> (29 bytes), 
> script=/home/alienhosting/public_html/webmail/src/read_body.php
> 
> This seems to happen a lot when using SquirrelMail with php 4.3.0RC4, 
> and AFAIK did not happen with 4.2.3. It seems that haystack_orig is 
> allocated at the beginning of the function, but only gets freed at the 
> end, and not if the function terminates early by e.g. RETURN_FALSE.
>

fixed in cvs, thanks.

-Sterling

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

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

[PHP-DEV] -+ [01]

[Sterling Hughes]

Hey,

Just clarifying: We never agreed that -+[01] meant anything except a short
way of:

-1 = I strongly disagree
-0 = I disagree
0 = neutral
+0 = I agree
+1 = I strongly agree

ie, We don't have a voting system.  If someone, let's call him Barney, says 
"-1 on this issue," all that means is that Barney disagrees, but that doesn't
(like in Apache circles[1]), mean that this is blocked.

Right?

-Sterling

[1] If Barney can give a technical reason for blocking it, and can offer an 
alternative solution.

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

Re: [PHP-DEV] CGI and CLI

[Sterling Hughes]

> This note from Derick pretty much reflects the idea... it makes sense:
> 
> I see that renaming the CGI to php-cgi might break things indeed, and 
> that's never a good idea. But so is changing the name of the CLI (php) 
> to something else. It also breaks things, not only for me, but also for 
> countless others using the CLI with the name 'php'. We also need to 
> think about these users as well. This leaves my opinion that i'm -1 on 
> renaming the CLI to something else, and i'm a -0 (yes this changed :) on
> renaming the CGI. This leaves the (IMO) only possible solution: 
> integrate them back into one binary and adding some magic which triggers
> CLI or CGI mode (perhaps to check for some environment variable).
> 
>

Hrmm, how does renaming php-cli break compatibility between PHP _releases_?

-Sterling

> 
> On Wed, 2002-12-18 at 14:59, Andrei Zmievski wrote:
> > What was the consensus on CGI vs. CLI naming or merging issue? Or was
> > there a consensus at all? I full plan to go ahead with 4.3.0 release
> > before the end of the year, so those interested in doing anything about
> > this issue better get their butts in gear.
> > 
> > -Andrei   http://www.gravitonic.com/
> > 
> > "This isn't right. This isn't even wrong."
> >-- Wolfgang Pauli
> -- 
> Xavier Spriet <[EMAIL PROTECTED]>
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM

[Sterling Hughes]

> Hi,
> 
> Tell me if this is the wrong list to ask or if this has been answered
> somewhere else before. Thanks :)
> 
> I am trying to make something like that:
> 
> $myClassName = 'MyClass';
> return $myClassName::myMethod($param1, $param2);
> 
> And I get :
> 
> Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM
> 
> I found a way to get around this by using:
> 
> return eval(("return $myClassName:: myMethod('$param1', '$param2');");
> 
> This works except when one of the parameters is an array.
> 
> What is this ?
> Is it a bug or a feature and will it change in ZE2 ?
> Is there another way to get around this to let it accept arrays ?
> 

Its neither, its a fact of the language, the following:

$classname::method is illegal, you recieved a parse error to that 
effect.  the best thing to do is::

call_user_func(array($className, 'method'), $param1, $param2);

-Sterling

> TIA,
> 
> Bertrand Mansion
> Mamasam
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] php-cgi vs php-cli naming issue

[Sterling Hughes]

> >I see that renaming the CGI to php-cgi might break things indeed, and 
> >that's never a good idea. But so is changing the name of the CLI (php) 
> >to something else. It also breaks things, not only for me, but 
> >also for 
> >countless others using the CLI with the name 'php'. We also need to 
> >think about these users as well. This leaves my opinion that i'm -1 on 
> >renaming the CLI to something else, and i'm a -0 (yes this 
> >changed :) on 
> >renaming the CGI. This leaves the (IMO) only possible solution: 
> >integrate them back into one binary and adding some magic 
> >which triggers 
> >CLI or CGI mode (perhaps to check for some environment variable).
> 
> I'm a bit nervous about the checking of an environment variable thing.
> Is that platform/server independent?
>

Can you name a platform that this wouldn't work on?

-Sterling

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

Re: [PHP-DEV] php-cgi vs php-cli naming issue

[Sterling Hughes]

> How about we simply add a configure option to control this?
> 
> --enable-simple-cli-name would build CGI as php-cgi and CLI as php
> 
> That way we preserve BC and let those who like CLI named 'php' have that
> too.
>

you mean instead of ::

# mv php-cli php

?

-Sterling

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

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

[Sterling Hughes]

> Just for the record, there is no fork() on Win32.
> 
> I have little doubt Sterling meant the Win32 equivalent :).
> 
> The only reason I felt this worth mentioning is that fork() on Unix is a
> relatively cheap operation, and an advantage unique to Unix.  Some have
> posted here of service providers that host huge numbers of low volume
> websites using PHP in CGI mode.
> 
> On Win32 you only have one choice - start a new php.exe instance on every
> request.  This is an expensive operation - possibly even more expensive than
> the equivalent operation on Unix.
> 
> On Unix you have another *potential* choice - load the php executable once
> and fork() on each request.  The presence of fork() on Unix offers (at least
> in theory) a unique performance advantage over Win32.
>

win32 supports fork in the way I was using it :), CGI semantics make your method
of implementation impossible.   CreateProcess() is the system call that is used.

If you really wanted something similair you could call CreateThread() which would
have the same effect.

-Sterling

> 
> -Original Message-
> From: Sterling Hughes [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 11, 2002 7:50 AM
> 
> Just as a note to this, under windows using PHP as a CGI is actually ideal
> when you're not serving high traffic stuff, like for example the company
> intranet, or a small extranet.  PHP is heavily used for such purposes, and
> you most likely won't run into a bottleneck from forking php in these cases.
> 

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

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

[Sterling Hughes]

> And no, PHP under Windows is rock solid as a CGI, so "they're already used 
> to having problems" approach doesn't apply (it wouldn't have applied either 
> way in my opinion, as having problems is not a reason to add another 
> problem, but still).
>

Just as a note to this, under windows using PHP as a CGI is actually ideal when
you're not serving high traffic stuff, like for example the company intranet, or
a small extranet.  PHP is heavily used for such purposes, and you most likely won't
run into a bottleneck from forking php in these cases.  

-Sterling

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

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

[Sterling Hughes]

> At 23:11 09/12/2002, Frank M. Kromann wrote:
> >>
> >> Please mention the name change at least in the NEWS file and maybe
> >php-cli
> >> could even output a readable error when beeing called as cgi.
> >
> >These are good points.
> 
> I think that's a bit like inventing problems and then trying to fix them.
> Let's keep it down to things we can determine relatively easily:
> 
> - Nothing bad will happen if we name the new CLI with whatever kind of name 
> - php-cli, phpsh, whatever
> - There WILL be some level of confusion if we rename the CGI binary
> 
> If we use this KISS approach, why the heck are we even considering this 
> rename?
>

I happen to agree with Zeev here - I won't argue the potential of using PHP
for GTK/command line scripting, however, currently that is not PHP's target 
audience, and in my opinion we should focus on our target audience first.

Should PHP progress and become more popular outside the webspace (and cgi 
becomes less popular as well :), then it would make sense to rechange the 
name (perhaps for PHPv5), but at this point changing it to php-cgi just seems 
like solving a problem by creating a bigger one.

-Sterling

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

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

Re: [PHP-DEV] Zend fast cache

[Sterling Hughes]

> At 07:17 PM 11/30/2002 -0500, Sterling Hughes wrote:
> >hrm. :)
> >
> >My only question is really about sequential accesses.  for the purpose of 
> >example
> >let's pretend its just for zvals...
> >
> >(pool is our pool array of zval structs)
> >ALLOC_ZVAL()
> > -> Do we have a zval available?
> >  -> yes!
> >   -> return pool[0][0]
> >
> >ALLOC_ZVAL()
> >...
> > -> return pool[0][1]
> >
> >ALLOC_ZVAL()
> >...
> > -> return pool[0][2]
> >
> >FREE_ZVAL()
> > -> Clear memory @ pool[0][1]
> >
> >ALLOC_ZVAL()
> > -> Do we have a zval available?
> >   -> return pool[0][3] or do we return pool[0][1]
> >
> >The problem I see with an array approach from an api perspective is simply 
> >when a bucket
> >is free'd, in order to have efficient memory usage, we'd need a second 
> >level array scan
> >for every ALLOC_ZVAL().
> >
> >Perhaps a linked list would be a better choice for this, as we can just be 
> >smart about bucket
> >access, and eliminate the need for a scan (could be possible I'm missing 
> >something?)
> 
> I think I was misunderstood. Of course I would want a free list.
> Check out the objects_store code in ZE2. The idea is to have something 
> similar. When we free allocated buckets we add them to a linked list. The 
> linked list is inside the structure itself, i.e., when the bucket isn't 
> used we can use its memory for the pointer to the next element. So 
> allocation just takes the bucket out of the free list. So basically the 
> bucket is a union between sizeof(zval) and sizeof(*) (or sizeof(int)).
> If it's still not clear I can explain it in a longer letter later on.
>

Ok, i understand - you basically are doing the linked list approach, but 
using a two-tiered storage paradigm to avoid fragmentation?

My only thought now is the dirty specifics:

1) Thread-safety: Will we have to mutex access to this cache?  We shouldn't
get corruption (I'd assume that on threaded environments we'd use a shared
cache) if we have multiple accesses, and if we mutex, we might as well malloc().

2) Growing buffer sizes.  Say we have a _really_ intensive script that does 
make us grow our zval/object/hashtable cache substantially, however, it is run
once every blue moon.  Do we after execution is finished than realloc() that huge
buffer back down to a normal size?  Or perhaps we should just malloc() after a 
certain size is reached  (ok, 16k of prealloc'd stuff, if we don't have a free 
slot, just do uncached mallocs).

-Sterling

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

Re: [PHP-DEV] Zend fast cache

[Sterling Hughes]

> At 02:59 PM 11/30/2002 -0500, Sterling Hughes wrote:
> >Hey,
> >
> >I was checking the CVS logs, and I read ::
> >
> >revision 1.13
> >date: 2001/11/26 17:27:59;  author: andi;  state: Exp;  lines: +1 -1
> >- Turn off fast cache until we make sure it performs well.
> >- The best solution is probably to limit its size.
> >
> >I was just wondering what was wrong, and what it would take to
> >get this thing up and running... Thies and I were looking at a
> >little hack, similiar in nature to this, with preallocating a pool of
> >zval's, and it yielded a 5% performance increase (all hacking credit
> >goes to thies btw :).
> 
> First of all, let me just say that I wouldn't be too excited about 5% 
> performance difference either way. I already told Thies that from my 
> experience 5% is within the error margin and can change according to 
> compile flags, platform and so on.

perhaps... this was 5% worse case though, comparing to similairly compiled
source trees.  In some cases it yielded 15-30% percent, but that can be
as you say, attributed to flukes.

Still, it would follow that having a memory cache would be a "good thing,"
even if it does only show 5% (on a small script btw)...

> The reason why the fast cache didn't work well was because it created quite 
> a bit of memory fragmentation which killed MT servers and also made PHP 
> take up too much memory.
>
> >If we preallocated some basic, often used types, i think we'd get a
> >nice performance increase, perhaps even if we initialized in sapi
> >modes a few structures in MINIT, we could reuse those instead of
> >creating and destroying which is currently quite expensive?
> 
> That said, I do think that if we can get very fast code to pre-allocate 
> zval's it would be a good idea (hopefully we could get more than 5% 
> increase).
> I already have an idea for how I would want such an API to look like and I 
> was planning to write it. It would also be useful for Zend objects which 
> are preallocated today but if a realloc() were to be reached it would take 
> quite some time (although one or two realloc()'s wouldn't be terrible).

no it wouldn't, and you've also gotta look @ this in terms of what would 
cause a realloc(), for example, say we have a 16 k pool, hardly anything, and
yet we'd need to have _a ton_ of concurrently allocated zvals in order to 
fill that up.

Plus, while the realloc would be expensive, it would be better than doing that
many mallocs.  Anyhow, we pretty much agree, soo :)

> My idea is a two dimensional array. We'd allocate 2^n of memory blocks and 
> assign it to array[0]. Once these are full we'd allocate another 2^n memory 
> blocks and realloc() array to size of 2 and make array[1] point to it. The 
> index to a block would be X and to find the right position it'd be 
> array[X/2^n][X%2^n] of course as the length of each array is a power of two 
> we wouldn't actually need to use division and modulo so it'd be fast.
> As we don't have templates in C we might be able to put all of this inline 
> in a header file and with macros create such a fast allocating pool for 
> some of the most used types specifically I think it'd be useful for zval's, 
> objects and possible hash tables. I wouldn't overdo the amount of types I'd 
> add to this pool because unless they are allocated and freed extremely 
> often we wouldn't notice a speed difference.
> 
> But remember what I said about 5% :)

hrm. :)

My only question is really about sequential accesses.  for the purpose of example
let's pretend its just for zvals...

(pool is our pool array of zval structs)
ALLOC_ZVAL()
 -> Do we have a zval available?
  -> yes!
   -> return pool[0][0]

ALLOC_ZVAL()
...
 -> return pool[0][1]

ALLOC_ZVAL()
...
 -> return pool[0][2]

FREE_ZVAL()
 -> Clear memory @ pool[0][1]

ALLOC_ZVAL()
 -> Do we have a zval available?
   -> return pool[0][3] or do we return pool[0][1]

The problem I see with an array approach from an api perspective is simply when a 
bucket
is free'd, in order to have efficient memory usage, we'd need a second level array 
scan 
for every ALLOC_ZVAL().

Perhaps a linked list would be a better choice for this, as we can just be smart about 
bucket
access, and eliminate the need for a scan (could be possible I'm missing something?)

-Sterling

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

[PHP-DEV] Zend fast cache

[Sterling Hughes]

Hey,

I was checking the CVS logs, and I read ::

revision 1.13
date: 2001/11/26 17:27:59;  author: andi;  state: Exp;  lines: +1 -1
- Turn off fast cache until we make sure it performs well.
- The best solution is probably to limit its size.

I was just wondering what was wrong, and what it would take to 
get this thing up and running... Thies and I were looking at a 
little hack, similiar in nature to this, with preallocating a pool of
zval's, and it yielded a 5% performance increase (all hacking credit 
goes to thies btw :).

If we preallocated some basic, often used types, i think we'd get a 
nice performance increase, perhaps even if we initialized in sapi 
modes a few structures in MINIT, we could reuse those instead of 
creating and destroying which is currently quite expensive?

-Sterling

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

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[Sterling Hughes]

> Is there any reason the ifdef __cplusplus doesn't work?  There shouldn't 
> be any need for extra processing or config options.
>

well, i think c++ code might confuse people just starting out writing a C
extension...

-Sterling

> J Smith wrote:
> >How about adding something like this to skeleton.c:
> >
> >/* __begin_extern_c__ */
> >/* __end_extern_c__ */
> >
> >And having the sed script in ext_skel replace them with the proper extern 
> >"C" stuff? That way there's no need for skeleton.cpp and just a few 
> >changes need to be made in skeleton.c.
> >
> >J
> >
> >
> >Sascha Schumann wrote:
> >
> >
> >>On Fri, 29 Nov 2002, J Smith wrote:
> >>
> >>
> >>>Attached is a patch to ext_skel that adds an optional argument (--cpp)
> >>>that will create a PHP extension in C++ rather than C. Also attached is
> >>>skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
> >>>modifications for using C++. I could've just made some changes to
> >>>skeleton.c and done some sed work in the ext_skel script, but I think
> >>>it's clearer to have them separated into two files.
> >>
> >>   I'm reluctant to duplicate the contents of the .c file for
> >>   maintenance reason.  Cannot you just put the C++ specific
> >>   code into a
> >>
> >>   /* Remove this part, if this is not a C++ extension */
> >>   #ifdef __cplusplus
> >>
> >>   #endif
> >>
> >>   section?
> >>
> >>   - Sascha
> >
> >
> >
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Sterling Hughes]

> On November 27, 2002 04:45 pm, Sara "Pollita" Golemon wrote:
> > That was one of the comments I was looking for "Is this really necessary?"
> >  After all the user can certainly use explode() to take it apart.  I'm not
> > against giving him that answer, it was just a quick patch to write...
> >
> > Is that a -1 then?
> 
> Yup, -1 from me.
> 

I disagree with this, the current behaviour is imho wrong.

mailto: is a url, rejecting the patch because it introduces a special case, 
is not a good thing.  parse_url() is for _all_ url's, not just http:// url's, 
and besides, the current syntax for mailto is completely valid, and should
be parsed anyway.

(ie, a special case shouldn't be required if the url parser was rfc compliant).

-Sterling

> >
> > > I am not so sure that adding special cases for things like mailto: and
> > > so on  is a good idea. The code works identically to how it worked in
> > > 4.2.3 and  prior.
> > >
> > > Ilia
> > >
> > > On November 27, 2002 04:19 pm, Sara "Pollita" Golemon wrote:
> > >> While waiting for opinions on Bug#20460 I went ahead and addressed
> > >> #20308.
> > >>
> > >> User complains that parse_url returns the full email address in 'path'
> > >> element.  Makes reference to documents which claim it should return
> > >> 'user' and 'host' element.
> > >>
> > >> To address this request and maintain backward compatability I wrote a
> > >> patch to split the 'path' element in to 'host' and 'user' elements
> > >> then return all three.
> > >>
> > >> Ex:
> > >> *current behavior*
> > >> print_r(parse_url("mailto:[EMAIL PROTECTED]";));
> > >> Array (
> > >>   [scheme] => mailto
> > >>   [path] => [EMAIL PROTECTED]
> > >> }
> > >>
> > >> *new behavior*
> > >> print_r(parse_url("mailto:[EMAIL PROTECTED]";));
> > >> Array (
> > >>   [scheme] => mailto
> > >>   [path] => [EMAIL PROTECTED]
> > >>   [user] => pollita
> > >>   [host] => php.net
> > >> }
> > >>
> > >> If there are no objections I'll commit this change.
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Sterling Hughes]

> While waiting for opinions on Bug#20460 I went ahead and addressed #20308.
> 
> User complains that parse_url returns the full email address in 'path'
> element.  Makes reference to documents which claim it should return 'user'
> and 'host' element.
> 
> To address this request and maintain backward compatability I wrote a
> patch to split the 'path' element in to 'host' and 'user' elements then
> return all three.
> 
> Ex:
> *current behavior*
> print_r(parse_url("mailto:[EMAIL PROTECTED]";));
> Array (
>   [scheme] => mailto
>   [path] => [EMAIL PROTECTED]
> }
> 
> *new behavior*
> print_r(parse_url("mailto:[EMAIL PROTECTED]";));
> Array (
>   [scheme] => mailto
>   [path] => [EMAIL PROTECTED]
>   [user] => pollita
>   [host] => php.net
> }
> 
> If there are no objections I'll commit this change.
> 
> 
I like the idea, just 2 little things with the patch...


> 
> Index: url.c
> ===
> RCS file: /repository/php4/ext/standard/url.c,v
> retrieving revision 1.59
> diff -u -r1.59 url.c
> --- url.c 14 Nov 2002 13:40:14 -  1.59
> +++ url.c 27 Nov 2002 20:44:25 -
> @@ -267,6 +267,26 @@
>   php_replace_controlchars(ret->path);
>   }
> 
> + if (strcmp(ret->scheme,"mailto") == 0) {
> + s = estrndup(ret->path, strlen(ret->path));
> + ue = s + strlen(ret->path);

why not cache this strlen() and not double calculate it.


> + p = s + 1;
> + /* a mailto starting with @ would be malformed, but let's keep it 
>clean */
> + if (s[0] == '@') {
> + s[0] = '\0';
> + }
> + /* scan for @ to separate user from host */
> + while (p < ue && p[-1] != '\0') {
> + if (p[0] == '@') {
> + p[0] = '\0';
> + }
> + p++;
> + }

why not use strchr() or memchr() for this code?

-Sterling

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

Re: [PHP-DEV] Bug #20460 (Feature Request)

[Sterling Hughes]

> >> Derick Rethans <[EMAIL PROTECTED]> wrote:
> >>
> >> > I don't like us adding a new ini entry for this, I think we should
> >> try  another option:
> >> >
> >> > 4) Make sure we can use fscanf on a dynamically sized buffer. This
> >> will  definitely the hardest solution, but also the most beautiful
> >> one.
> >>
> >
> I'll admit to not knowing what you mean by 'dynamically sized buffer's. 
> Is there an example of another function which works with such?
>

a php function, not sure, spprintf() is a perfect example though (in C).

Basically, a dynamically sized buffer is a buffer that grows or shrinks
when necessary (dynamically :)

Anyhow, I've got fscanf() doing what you wanted in CVS (as well as the 
release branch), give it a try, and see if it meets your needs.

-Sterling

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

Re: [PHP-DEV] Bug #20460 (Feature Request)

[Sterling Hughes]

> > err. it didn't need a reimplementation, i fixed it, it works fine in cvs.
> 
> Then,
> 
>$buf = "123 456 \0 567"
>   sscanf($buf, "%d%d%s%d", $a, $b, $c, $d);
>   var_dump($a, $b, $c, $d);
> ?>
> 
> How about this?
> 
> The result was the same as for fscanf.
>

Yes, but it didn't need a reimplementation as far as using arbitrary buffer 
sizes.

-Sterling

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

Re: [PHP-DEV] Bug #20460 (Feature Request)

[Sterling Hughes]

> > 
> > I don't like us adding a new ini entry for this, I think we should try 
> > another option:
> > 
> > 4) Make sure we can use fscanf on a dynamically sized buffer. This will 
> > definitely the hardest solution, but also the most beautiful one.
> 
> I like this fourth option, because the internal scanf function will anyway 
> need reimplementation since it's not binary safe.
>
err. it didn't need a reimplementation, i fixed it, it works fine in cvs.

-Sterling


> Moriyoshi
> 
> > Derick
> > 
> > -- 
> > 
> > -
> >  Derick Rethans http://derickrethans.nl/ 
> >  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> > -
> > 
> > 
> > -- 
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] Bug #20460 (Feature Request)

[Sterling Hughes]

> User complains that maximum length of a line used by fscanf is too short
> (he has lines > 1600 chars).  Looking at file.h I agree (it's only 512).
> 
> The user requested two options:
> 
> 1) Add an optional length field.
>   No way to do that without breaking parameter list. :(
> 
> 2) Increase to a larger arbitrary number.
>   This simply has the problem that it may prove too short eventually as well.
> 
> Plus I came up with a third option:
> 
> 3) Create an .ini entry to specify the maximum length used.
>   I think this has the best overall return on it.
> 

The thing is that just feels kinda dirty (an ini option controlling how long a
line should be assumed for fscanf, but I agree there is no really good solution), 
unless of course it means changing the parameter order to fscanf().

-Sterling

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

Re: [PHP-DEV] call_stack

[Sterling Hughes]

> On Wed, 27 Nov 2002 15:41:25 +0100 (CET)
> Derick Rethans <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 27 Nov 2002, Miham KEREKES wrote:
> > 
> > > Hi!
> > > 
> > > I'm new to this list, I want to know if there is any function which
> > > could return the actual call stack, or is it planned to be added?
> > > It could be very useful (for example in my case, now :-).
> > 
> > debug_backtrace() will be available in PHP 4.3.0 and higher.
> > 
> > Derick
> > 
> 
> I thought debug_backtrace() was a ze2 thing.  Does that mean 4.3 is going to
> use ze2?
>

it has been backported...

-Sterling

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

Re: [PHP-DEV] Redirect on Error (not localisation)

[Sterling Hughes]

> 
> Unless told otherwise, I'm already planning on making a few changes and
> committing.
>

john,

I've told you otherwise, so has derick and about half the developers on this
list (not talking about the localization portion of the thread here).

Quick answer: don't.  If you wanna come with some patches, post them on your
website, i and other people will be happy to look @ them and discuss them, 
but *do not* commit them without a reasonable concensus.

-Sterling

> John
> 
> 
> >-Original Message-
> >From: Ivan Ristic [mailto:[EMAIL PROTECTED]] 
> >Sent: Tuesday, November 26, 2002 2:50 PM
> >To: [EMAIL PROTECTED]
> >Cc: 'James Aylett'; 'PHP Developers Mailing List'
> >Subject: [PHP-DEV] Redirect on Error (not localisation)
> >
> >
> >
> > > Anyway... So what of my actual patch we were discussing at
> > > some point? I never got a real answer as to if it would be
> > > suitable to commit.
> >
> >I have changed the subject of the message in an effort to
> >separate the discussion on the "Redirect on Fatal Error" feature
> >(the subject of this email) from the localisation discussion.
> >
> >...
> >
> >As a reminder, we are discussing a patch that will redirect
> >the user to another page when a fatal or a parse error occurs
> >(parse errors can be caught with lint, fatal can't). The
> >redirection will allow developers to:
> >
> >* Show a decent page to the user (instead of letting them
> >  see a blank or incomplete page)
> >
> >* Send a message to themselves that something
> >  strange has happened (allowing them to react quickly, instead
> >  of having to install log watch software for notification
> >  purposes (and many people cannot do that as they do not
> >  have control over the servers))
> >
> >As far as I am aware, there is not a single reason not to
> >have this feature. Some people seem not to like it, but that
> >is fine; with no performance or stability risks, if you don't
> >want to use the feature - you won't be affected.
> >
> >On the other hand, I will be extremely happy to have it under
> >my belt as yet another tool I can use to make my software
> >run better.
> >
> >Please don't tell me that I wouldn't need this feature if
> >I programmed perfectly. Errors happen all the time, no matter
> >what you do trying to prevent them.
> >
> >
> >Bye,
> >Ivan
> >
> >
> >
> >
> >-- 
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

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

[Sterling Hughes]

> MySQL also supports error message internationalization - one more RDBMS 
> to annoy Sterling, I guess.
> 

MySQL IS NOT A RDBM.

Besides that, I've said my piece, anyhow, i think its stupid, I'll wait till I 
see a patch to disagree fully :)

-Sterling


> George
> 
> On Monday, November 25, 2002, at 08:47 PM, Maxim Maletsky wrote:
> 
> >
> >It was to say that these three (Oracle, SQL and DB2) do have
> >internationalized error reporting. I meant them as an example for the
> >one PHP has.
> >
> >-- 
> >Maxim Maletsky
> >[EMAIL PROTECTED]
> >
> >
> >On Mon, 25 Nov 2002 20:44:03 -0500 George Schlossnagle 
> ><[EMAIL PROTECTED]> wrote:
> >
> >>Is your claim that db2 has no international error messages? It does, 
> >>or
> >>did last I checked.  Or was it that SQLServer doesn't either (it does
> >>as well).
> >>
> >>
> >>On Monday, November 25, 2002, at 08:24 PM, Ilia A. wrote:
> >>
> >>>On November 25, 2002 08:15 pm, Maxim Maletsky wrote:
> On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen 
> <[EMAIL PROTECTED]>
> >>>wrote:
> >Just forget this. I'm not native english speaker, but I REALLY
> >don't want to see any errors in any other language but english.
> >(does Perl/Python/etc have multi-lingual errors btw?)
> >
> >--Jani
> 
> The world's most powerful database server does - Oracle. And, just
> type
> something out of the place and you will get them dozens :)
> >>>
> >>>That's arguable, there are many people who would say the same about
> >>>IBM's DB2.
> >>>According to TPC
> >>>(http://www.tpc.org/tpcc/results/tpcc_perf_results.asp)
> >>>Microsoft SQL Server 2000 is faster and has lower cost per
> >>>transaction. So
> >>>claims about greatness of Oracle and greatly exaggerated.
> >>>
> >>>Ilia
> >>>
> >>>-- 
> >>>PHP Development Mailing List 
> >>>To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>
> >>
> >>-- 
> >>PHP Development Mailing List 
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

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

[Sterling Hughes]

> 
> 
> On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes <[EMAIL PROTECTED]> wrote:
> 
> > Educate users to speak the base amount of english required, I18N'ing the 
> > language is just going to lead to headaches from a user perspective 
> > (incorrect translations, slower performance, translations for english speakers)
> > and a developer perspective (having to lookup tokens, understanding another
> > language, getting bug reports with horrible error messages).
> 
> That is why we have error codes :)
>

Bull, that's why we don't obfusticate :)

> Are you saying that Oracle is wrong giving the ability to localize even
> SQL error messages? These does not have to ever happen, but in my
> Italian team the guys are simply rocking - they find out instantly what
> they did wrong to a query because it is in their language.
> 

Kinda funny, This summer I worked w/ Oracle in German, I survived.

Same for SAP

I spent about 15 minutes to learn the terms, and was set, besides using the 
german terms when all the german SAP consultants used the English terms 
(bedarfsbestandliste, stammdaten, lallalaa).

If there was an error, I asked a colleague or looked it up on the internet - 
I survived.

This happens to tons of php developers across the world, its not really that 
hard, and it really does open up pandora's box, also from an implementation 
perspective, its alot more feasible for Oracle than for PHP...

-Sterling

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

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

[Sterling Hughes]

> On Monday 25 November 2002 23:29, Daniel Lorch wrote:
> > You're right. We should think about writing a colorful GUI for PHP, so
> > scripts just can be clicked together. Oh, and it definitively should
> > support skins..
> 
> I don't think this would work.
> But if it did, it's place wouldn't be inside the language. Either in an IDE or 
> in a PHP-application. PHP often is used for skinning a website, btw.
> 
> But if there were a good idiot-proof IDE, it would definately help these 
> people. It would have to be free (beer), of course. People who spend 2,50€ a 
> month on webspace won't spend a fortune on an IDE.
> On the other hand, you lose a lot of flexibility this way. At some point, 
> people will have to touch the code. And there should be as few obstacles as 
> possible.
> 
> > I can absolutely understand your argumentation (which you forgot to CC to
> > the list, by the way) and being a regular to PHP-DE (german PHP users
> > mailinglist), I am also in touch with people you described. But what's
> > wrong about just HREF'ing to the manual, which is localized anyway?
> 
> You'd have to put a href in every single error-message. Ugly.
> Either this, or people won't find it.
>
We're already doing this :)

-Sterling

> 

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

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

[Sterling Hughes]

> I'm not really arguing for or against this, but since when did speaking 
> english become a corollary of being intelligent?  And even if we accept 
> the rather ridiculous hypotheis that all php developers can comprehend 
> english, what if they don't want to, or are more confident using their 
> native tongue in day-to-day work?  Why deny that to them on prinicple?
>

Well, speaking english as a corollary for intelligence, perhaps not, 
education most likely.  I've spoken to very few PhDs abroad that don't speak
english, I've spoken to quite a few Supermarket checkout people that don't 
speak english.

But that's another discussion. :-)

> Plenty of products support multi-lingual errors in the way John 
> describes.  In fact there's an argument that constant-based error codes 
> are even easier to describe than verobose english descriptions, as they 
> leave no room for ambiguity due to re-phrasing.
>

They also make it incredibly unintuitive :)

There needs to be a medium between maintainability and sanity.  Understanding
basic english can be a requirement.  If they really have problems, they can
read the docs which explain the errors to users who don't speak english...

The question is - what language does this different?

Perl, Python, Ruby, Java, C++, C all have english only error messages.

Anyhow, until someone comes up with a viable implementation, the thought of
whether this belongs in the language is pretty much right. :)

-Sterling

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

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

[Sterling Hughes]

> >fine - provide documentation / translations for what these error codes
> >mean in the documentation (on a per-translation basis, or in an extra
> >page listing all the translation).  php_error_docref() already does
> >this I believe (cookie variable, or just click on the link).
> 
> php_error_docref() simply points to the function descriptions. But there
> could be error descriptions which would then be translated. However most
> of us do not describe errors and errors are changing sometimes
> 

Right.  When the user gets to the function descriptions, they can then 
click on the language they wish to see that in (and I believe a cookie 
is created when you do that, so you always see the manual in your language).

-Sterling



> marcus
> 

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

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

[Sterling Hughes]

> > Whereas assuming that PHP users are too stupid to understand english is
> > not at all arrogant? :)
> 
> Wrong, Sterling.  Beginning PHP users might neither have
> formal education in computer science _nor_ foreign languages.
> The reason here is not about intellect; it is about requiring
> certain knowledge.  Presuming that someone else must speak
> your language is quite self-centered.
> 
> Alas, if your view was correct (users must understand
> English), then we could just scrap the whole translation
> effort.  I don't think that it's realistic.
> 

Not at all, i don't expect them to speak fluent english, just to understand the
small subset of english errors and programming terms.  I've conversed with plenty
of PHP users (second-hand at least) where they didn't know english, yet understood
the error codes.  Users need not know english, they can download a quicksheet.

If you see

Constant 3

And I tell you it means:

Undefined constant, assuming string

after a while that term will become like your own language, especially if its as
simple as copying & pasting, and clicking search.


> > What you're missing is that currently to program PHP, you need a reasonable
> > understanding of english.
> 
> I don't think so.  The translations of the PHP manual do a
> fine job at relaying all necessary information about
> programming in PHP to speakers of foreign languages.
> 

And they'll do a fine job of explaining the error codes too.


> > Educate users to speak the base amount of english required, I18N'ing the
> > language is just going to lead to headaches from a user perspective
> > (incorrect translations, slower performance, translations for english speakers)
> 
> The performance is negligible -- error messages are displayed
> during the development phase, not in a production
> environment where run-time behaviour is important.
> 

how do you see this being implemented?


> The "incorrect translations" argument applies to all
> translations, regardless where and when they are displayed.
> Online translations can be centrally maintained, of course,
> which is an advantage.  This can be addressed by providing
> stand-alone message catalogues which can be downloaded by
> administrators.
> 

yes, if they update it.

If its in the docs, you don't really have to worry about users using an outdated 
version of the translation.


> > and a developer perspective (having to lookup tokens, understanding another
> > language, getting bug reports with horrible error messages).
> >
> > The whole i18n thing can be solved by just listing the translations of
> > the error codes on the doc page, let's do that, instead of bloating the
> > PHP infrastructure.
> 
> Frankly, so far the discussion has been primarily
> developer-focused, which is not too surprising.  The
> developers are rarely exposed to support requests from
> newbies in various non-English forums.
> 
> If PHP is supposed to become easier to use, then native
> language error messages would be a big hit.
>

I agree.  Unfortunately I think you mean a big bonus. :)))

-Sterling

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

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

[Sterling Hughes]

> If this thread was about error messages of a C compiler, I
> would agree that users can be expected to understand English.
> That is a completely different level you are dealing with then.
> However, PHP needs to take beginners into account.
> 
> Simply assuming that everyone must understand English
> is arrogant.
>

Whereas assuming that PHP users are too stupid to understand english is
not at all arrogant? :)


> PHP is used by people around the world; it is used by many as
> first computer language who just started out to conquer a new
> area of knowledge.  They do not necessarily speak English
> adequatly or are able to make sense of technical English
> terms.
> 

fine - provide documentation / translations for what these error codes
mean in the documentation (on a per-translation basis, or in an extra 
page listing all the translation).  php_error_docref() already does 
this I believe (cookie variable, or just click on the link).

> This issue came up years ago with a certain operating system.
> If localized error messages are provided, they must be
> presented together with a unique message id.  That unique
> token enables people who speak a different language to
> interprete the error code/message and provide support/answers
> as necessary.

Great, I'll look up IE55343 everytime i get a question about an undefined
variable.

What you're missing is that currently to program PHP, you need a reasonable
understanding of english.  To my knowledge mandarin does not have the 
string length, most everything in the programming world is in english, 
therefore, a basic understanding of english becomes a prerequisite.

Educate users to speak the base amount of english required, I18N'ing the 
language is just going to lead to headaches from a user perspective 
(incorrect translations, slower performance, translations for english speakers)
and a developer perspective (having to lookup tokens, understanding another
language, getting bug reports with horrible error messages).

The whole i18n thing can be solved by just listing the translations of 
the error codes on the doc page, let's do that, instead of bloating the 
PHP infrastructure.

-Sterling

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

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

[Sterling Hughes]

> 
> >Multi-lingual error codes open's up pandora's box, let's not go 
> >there.
> 
> I have to disagree with you here Sterling. Worrying about support for
> non-english errors in php-general, etc is a bad, bad excuse not to
> implement them. The benefits of a completely constant-based error system
> (with human-friendly errors just because we like them) is worth
> consideration and I really feel is a positive addition to PHP. The only
> pandora's box your worried about (at least from the sound of your
> e-mail) was your inbox size ;) Or am I missing something?
>

you're missing alot.

Its not inbox size, when you get multi-lingual error messages you have more
than one problem.

1) Support.  This makes it hell for companies and users alike to support.
Sure, there are localized mailing lists, but chances are if you are a 
programmer these days you can at least read english enough to understand 
the error messages.  English is soo prevelant in the computer world (ie, 
terminology is most often borrowed, unless your french and send Courier 
Electronique messages), that its really a non-issue.  Also finding a 
translation of the error messages shouldn't be that hard.

If you want to support a multilingual error messages, perhaps a page that 
translates all the error messages for multi-lingual users to look up the
translation is a good medium, but putting it into php leads to our next 
problem.

2) Implementation.  Compile time generation of error messages is a very
bad thing, changing error messages on a binary can lead to a pain in the
ass when you need to take over a project, and *gasp* all the error 
messages are in Mandarin, english translations of errors should always 
be available.

If you do this at execution time, you either need an extra php function
set_error_language(), which is kinda silly, or you need to respect locales
which isn't thread safe.  Add to that the overhead of parsing the error
messages for every language, and execution time really doesn't become a
reality.

Also, you have translator error in many cases.  I know plenty of people 
from other countries who go to google.com/en, just to force the language
to english.  If the translator makes a slight error in the translation, 
you've just given the end user a headache and a half trying to figure out
where the undefined function was, even though it was an undefined variable :)

3) Everything else is in english.  Well, ok, the documentation is partially
translated, but most things in the programming world are english.  Chances 
are that users can learn what the error messages are without much trouble, 
at least its easy enough to counterbalance the amount of effort required 
to properly internationalize error messages.

> >In conclusion to both (imho):: 
> >English is fine.  Uncatcheable parse errors is also fine. 
> 
>  
>$answer = ($fine == $best);
>echo "Result: $answer";
> 
> ?>
> 
> Result: false
>



Result: Who cares about the answer

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

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

-Sterling

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

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

[Sterling Hughes]

The question is: why would your production code have fatal 
errors?

A fatal error occurs because of one of the following reasons:

1) parse error
2) engine instability
3) segfault (well, kinda, its nothing catchable, but it is about
as fatal as you can get :)

2 & 3 are very very rare cases, and are almost always bugs in PHP
itself.  case 1, well, if you've tested your code properly (or at 
all) you shouldn't be getting this error...

I don't get why revising the error scheme (even Maxim's proposal) is
really that useful, it seems like a lot of extra work for something
that is good enough (i'd say ideal).

As for multi-lingual errors, no, no, no, no, no!

ohh yeah, and no!

I can just imagine the support requests coming to php-general@ 
(and my private inbox, which unfortunately gets comparable traffic
these days) with foreign error strings.  Most programming is in english
these days, including function names, external libraries, classes, 
etc.  Also, to implement this with any reasonable efficiency, we 
couldn't use dynamic locales, which will make it quite annoying 
for external contractors to work on pieces of code.

Multi-lingual error codes open's up pandora's box, let's not go 
there.

In conclusion to both (imho):: 
English is fine.  Uncatcheable parse errors is also fine. 

-Sterling

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

Re: [PHP-DEV] curl_exec hangs

[Sterling Hughes]

> Good morning,
> 
> I am using curl to send xml string to my merchant's account gateway when
> curl_exec() executes the xml is successfully received by its destination but
> I am not getting anything back (it just hangs) Could anyone help me with
> this problem?
>

Hi, 

I'm sure someone could - ask it on [EMAIL PROTECTED]!

-Sterling

-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/curl config.m4

[Sterling Hughes]

> On Sat, 9 Nov 2002, Sterling Hughes wrote:
> 
> >> On Sat, 9 Nov 2002, Sterling Hughes wrote:
> >> 
> >> >> 
> >> >> There is no such release of Curl yet. This makes testing
> >> >> the RCs quite a hassle now so either you revert those changes
> >> >> or get the curl folks to release this 7.10.2. 
> >> >> 
> >> >> --Jani
> >> >>
> >> >
> >> >7.10.2-pre4 is currently out, it should be released quite soon.
> >> 
> >> But it's not 7.10.2 release. Revert the changes.
> >> Or I will.
> >>
> >
> >err... no.
> >
> >7.10.2 will be out long before PHP 4.3.  We haven't even had the first
> >RC for PHP, and its a lot longer before PHP releases to come out.  If
> >you want to test it for QA purposes, you can easily install one of the
> >prereleases.  7.10.1 might also work, not sure
> 
>  You're now missing the point here. I'm NOT doing QA for Curl.
>  I'm not going to install ANY curl pre-release here.
>  
>  You can (if you wouldn't be so lazy) add some ifdef's around
>  the new stuff instead of everytime requiring people to update curl!!

Its not laziness... I'm not having that many '#ifdef's in the code.
Some cases it makes sense for cURL to have #ifdef's, in some cases it'll
just make the code both unreadable and unmaintainable. 

The solution I'm working on is to autogenerate from the curl.h and
multi.h files.   However, that's after i get the multi interface in, and
the cURL extension is hopefully up-to-date.

Anyhow, I get the point.   I just don't find it valid, if you're
doing QA, than upgrading to a pre-release is not that much harder than
upgrading to the release itself.

PHP-Curl is _not_ that often tested in the QA process, simply because
most features rely on a server being available, and with PHP/QA there is
none.  Therefore, very few regression tests.

-Sterling

-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] Do I need the closing ?> tag

[Sterling Hughes]

> PHP 4.2.2 (linux) doesn't seem to mind if I leave off the closing ?> tag at
> the end of a file.  Is the ?> assumed at EOF?
> 
> I have PHP that outputs binary and along the way I include() a lot of php
> scripts.  I'm constantly having problems when I leave a little whitespace at
> the end of some script after the ?> which screws up the output binary.
> First time this happened it took me hours to figure out the cause.
> 
> What does everyone think about just leaving off the ?> as a solution to
> this?  It works for me now, but would any PHP developer care to
> prognosticate on the liklihood this might change in future?
> 

I definitely think that _you_ should do it.

But this is not the proper place for these questions, ask them on
[EMAIL PROTECTED]

?> Sterling


-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] turning strlen() into an opcode

[Sterling Hughes]

> On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote:
> 
> > I've made a small patch that turns strlen() into a statement executed by
> > the engine instead of a function. The reasoning is that something that
> > integral should probably be in the engine. I haven't done hard
> > benchmarking but it seems to improve performance of that particular
> > piece of code by about 25%. Feedback is welcome.
>  
> I'd be more interested in seeing a more generic len() function (a la
> Python) that would return the length of the variable passed to it (the
> number of characters in a string, then number of elements in an
> array).  Actually, I suppose extending count() to handle strings would
> be mostly equivalent.
>

ughh, no more syntatic sugar, php is sweet enough how it is :)

-Sterling


> -- 
> Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

[PHP-DEV] Re: #19848 [Ctl->Csd]: Wrong $_REQUEST values ($_FILES appearanceis wacky)

[Sterling Hughes]

On Mon, 2002-10-28 at 03:51, Philip Olson wrote:
> 
> This change will make it into 4.3.0 right?  Also, 
> is import_request_variables() affected?
> 

i don't know about 4.3, not really my area...

as for import_request_variables, I haven't modified that, simply because
i'm not sure whether it should be modified...  For now I'll leave it, if
someone feels strongly about it either way, they can change it...

-Sterling


> Regards,
> Philip
> 
> 
> On 28 Oct 2002 [EMAIL PROTECTED] wrote:
> 
> >  ID:   19848
> >  Updated by:   [EMAIL PROTECTED]
> >  Reported By:  [EMAIL PROTECTED]
> > -Status:   Critical
> > +Status:   Closed
> >  Bug Type: HTTP related
> >  Operating System: *any
> >  PHP Version:  4.2.3,4,3.0-dev
> >  Assigned To:  sterling
> >  New Comment:
> > 
> > Fixed in CVS... $_FILES is no longer present in $_REQUEST...
> > 
> > 
> > Previous Comments:
> > 
> > 
> > [2002-10-24 18:42:14] [EMAIL PROTECTED]
> > 
> > This test form strips 3 characters from the posted variable:
> > 
> > 
> > 
> > 
> > 
> > 
> > 2 dimensional array - this test form strips 8 characters from the
> > posted variable:
> > 
> > 
> > 
> > 
> > 
> > 
> > For every dimension added to the array, another 4 characters are
> > scripted from the beginning of the posted variable.  Works on PHP
> > version less than 4.2.2 and earlier.
> > 
> > 
> > 
> > [2002-10-20 22:17:12] [EMAIL PROTECTED]
> > 
> > The 'voting' on php-dev was in favour for removing the $_FILES from
> > $_REQUEST..as it doesn't make much sense
> > to have them there. Just FYI. :)
> > 
> > --Jani
> > 
> > 
> > 
> > 
> > [2002-10-20 22:14:01] [EMAIL PROTECTED]
> > 
> > Sterling Hughes is working on this issue, according to posts to
> > php-dev.
> > 
> > 
> > 
> > 
> > [2002-10-16 06:29:23] [EMAIL PROTECTED]
> > 
> > Also got the same cases.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > print_r($_POST['server']);
> > 
> > it comes out:
> > ---
> > Array 
> > ( 
> > [0] => ASP 
> > [1] => C# 
> > [2] => FUSION 
> > [3] => 
> > [4] => 
> > [5] => PHP 
> > ) 
> > 
> > Apache/1.3.26, Win98
> > 
> > 
> > 
> > [2002-10-15 15:21:27] [EMAIL PROTECTED]
> > 
> > BTW, 17958 is "no feedback".
> > Well, that's pretty untrue ...
> > 
> > 
> > 
> > The remainder of the comments for this report are too long. To view
> > the rest of the comments, please view the bug report online at
> > http://bugs.php.net/19848
> > 
> > -- 
> > Edit this bug report at http://bugs.php.net/?id=19848&edit=1
> > 
> 
-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Sterling Hughes]

On Tue, 2002-10-22 at 01:38, Alan Knowles wrote:
> Non blocking connections would be nice...
> 
> - On the generating stuff - why do you want to generate the code on the 
> users system? -
> all the re2c stuff in CVS is 'pre-genereated'
> 
> It would be nice to have extension generator that could be built upon, 
> that didnt involve re-reading all those perl/awk manuals, just to add 
> features to it. :)
> Any idea if  finding 'generic' bits in the php-gtk generator is possible?
> 
Well, the reason for the generator, is it will build an extension that
mimics the current version of cURL installed which will allow the cURL
extension to support multiple versions of the library without a lot of
maintanence and stuff :)

-Sterling


> Regards
> Alan
> 
> 
> Sterling Hughes wrote:
> 
> >Hi,
> >
> >I'm going to be working on updating the PHP cURL extension in the coming
> >weeks: 
> >
> >* adding the multi-interface. 
> >* ssl session id caching (globally) 
> >* global dns cache in threaded webservers (same for ssl sesssion id
> >caching)
> >* allowing cURL handle re-use.
> >* allowing "persistent" cURL handles that survive the request, for HTTP
> >1.1 persistent connections
> >* Autogenerating much of the interface between cURL and PHP, allowing
> >PHP to support multiple versions of the underlying cURL library
> >* Supporting all cURL options/callbacks in one way or another
> >* Adding a OOP interface to cURL, on the extension level... [undecided]
> >* Updating the cURL documentation
> >
> >So, I'm sending this message, to the lists just to get any suggestions,
> >comments, feature requests, bug reports that you would like me to look
> >at/consider when revamping the extension.  The changes will be done step
> >by step to the extension, but the full revamping should be expected
> >around the time of PHP 5 (PHP 4.3 is too soon for all these changes to
> >be integrated and tested).
> >
> >-Sterling
> >
> >PS: I'll be at the PHP Conference in Frankfurt, and ApacheCon in Las
> >Vegas, if you're coming to either of those, feel free to talk about it
> >with me there as well...
> >
> >  
> >
> 
> 
-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Sterling Hughes]

On Mon, 2002-10-21 at 22:46, Shane Caraveo wrote:
> Sterling Hughes wrote:
> > On Mon, 2002-10-21 at 22:15, Jon Parise wrote:
> > 
> >>On Mon, Oct 21, 2002 at 10:12:55PM +0200, Sterling Hughes wrote:
> >>
> >>
> >>>* Autogenerating much of the interface between cURL and PHP, allowing
> >>>PHP to support multiple versions of the underlying cURL library
> >>
> >>By what mechanism do you plan on implementing this?
> >>
> > 
> > 
> > Well, currently i plan on using a Perl script to read the curl.h
> > definition file, and generate the code for all options that don't meet
> > the following criterium:
> 
> What, you can't write a simple parser in php?  Off with his head! ;)
> 

;

Yeah, but then you get into the recursive dependency problem (otherwise
i would).  You need PHP in order to build PHP, and that just gets messy
;)

-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Sterling Hughes]

On Mon, 2002-10-21 at 22:15, Jon Parise wrote:
> On Mon, Oct 21, 2002 at 10:12:55PM +0200, Sterling Hughes wrote:
> 
> > * Autogenerating much of the interface between cURL and PHP, allowing
> > PHP to support multiple versions of the underlying cURL library
> 
> By what mechanism do you plan on implementing this?
> 

Well, currently i plan on using a Perl script to read the curl.h
definition file, and generate the code for all options that don't meet
the following criterium:

1) There is a definition in for the constant in the file
php4/ext/curl/objects.def, in the form of something like:

CURLOPT_OPTNAME: {
// code goes here
}

2) the type of the constant is OBJECTPOINT

(the words "type" and "constant" are used loosely here :)

Then for constants that are definied in both curl/objects.def and
curl.h, i'll add the code for them into curl.c.  Any other constants
will get simply get the "undefined constant" warning with E_ALL and cURL
will complain that the constant doesn't exist when curl_setopt() is
used, at least this is the current plan for auto-generation.

I'm also debating just having a standard (generated from the latest
stable cURL version) file, in case Perl is not present on the users
system (but if Perl isn't present on your system - that's pretty bad :)

-Sterling




--
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

[PHP-DEV] Work is beginning on cURL and PHP again

[Sterling Hughes]

Hi,

I'm going to be working on updating the PHP cURL extension in the coming
weeks: 

* adding the multi-interface. 
* ssl session id caching (globally) 
* global dns cache in threaded webservers (same for ssl sesssion id
caching)
* allowing cURL handle re-use.
* allowing "persistent" cURL handles that survive the request, for HTTP
1.1 persistent connections
* Autogenerating much of the interface between cURL and PHP, allowing
PHP to support multiple versions of the underlying cURL library
* Supporting all cURL options/callbacks in one way or another
* Adding a OOP interface to cURL, on the extension level... [undecided]
* Updating the cURL documentation

So, I'm sending this message, to the lists just to get any suggestions,
comments, feature requests, bug reports that you would like me to look
at/consider when revamping the extension.  The changes will be done step
by step to the extension, but the full revamping should be expected
around the time of PHP 5 (PHP 4.3 is too soon for all these changes to
be integrated and tested).

-Sterling

PS: I'll be at the PHP Conference in Frankfurt, and ApacheCon in Las
Vegas, if you're coming to either of those, feel free to talk about it
with me there as well...

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

[PHP-DEV] Re: Curl Multi Interface Patch

[Sterling Hughes]

On Sun, 2002-10-20 at 02:16, Boris Bukowski wrote:
> 
> > ok, i can see the use in that, however, i think it can be more useful if
> > you give the user the option of when to use the select() call - that's
> > the whole point of the cURL multi interface, and while it may be useful
> > in this case, the interface was designed to be much more powerful, and
> > this patch does take a lot of that power away.
> There is no change on the interface, only the additional feature to execute
> the curl sessions parallel. After the curl_multi_exec you can use curl_info,
> curl_errno without problems. curl_get_content is needed cause curl_multi_exec
> cant return content if RETURNTRANSFER is Set. Do you see a better way to 
> become the Content ?
> 

The interface change is not related to what is currently in the PHP
interface but rather what the cURL multi interface is supposed to be,
and how the interface proposed hides some of the inherent power of that
interface.

-Sterlingg


> Boris
> 
> 
> 
> 


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

[PHP-DEV] Re: Curl Multi Interface Patch

[Sterling Hughes]

On Sun, 2002-10-20 at 01:23, Boris Bukowski wrote:
> Am Saturday 19 October 2002 23:59 schrieb Sterling Hughes:
> > On Sat, 2002-10-19 at 15:42, Boris Bukowski wrote:
> > > Hi,
> > >
> > > now I made a Patch that is hopefully ok for you ;^)
> > >
> > > I introduced the following functions:
> > >
> > > curl_multi_init();
> > > curl_multi_add ($multi,$ch1);
> > > curl_multi_add ($multi,$ch2);
> > > curl_multi_exec($multi);
> > > curl_get_content($ch1);
> >
> > Why would this patch be useful, your implementation of curl_multi_exec()
> > kinda defeats the whole purpose, doesn't it?
> No,
> 
> It executes every curls session you add to a multi session in parallel.
> if you have 10 sources with 1 second Latency you need only 1.2 Seconds
> to fetch them, not 10 Seconds.
> I think that is useful.
> 
> If you look on our search Page:
> http://search.lycos.co.uk/cgi-bin/pursuit?query=cars
> You find Sponsored Links, News, Fast Search Results, our Directory Search and 
> the Ads on the right side. HTTP Requests around the half World. The added 
> Latence is around 7 Seconds.
> 
> This moment we are using an additional Apache with a threads based Solution.
> That one is a little bit ill and I will replace it with the curl multi 
> interface.
> 

ok, i can see the use in that, however, i think it can be more useful if
you give the user the option of when to use the select() call - that's
the whole point of the cURL multi interface, and while it may be useful
in this case, the interface was designed to be much more powerful, and
this patch does take a lot of that power away.

-Sterling

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

[PHP-DEV] Re: Curl Multi Interface Patch

[Sterling Hughes]

On Sat, 2002-10-19 at 15:42, Boris Bukowski wrote:
> Hi,
> 
> now I made a Patch that is hopefully ok for you ;^)
> 
> I introduced the following functions:
> 
> curl_multi_init();
> curl_multi_add ($multi,$ch1);
> curl_multi_add ($multi,$ch2);
> curl_multi_exec($multi);
> curl_get_content($ch1);
> 


Why would this patch be useful, your implementation of curl_multi_exec()
kinda defeats the whole purpose, doesn't it?

-Sterling

> thx, 
> 
> Boris 
> 
> 

>  // creates a multi session
> $multi = curl_multi_init();
> 
> // start of a normal easy session
> $ch1 = curl_init("http://192.168.4.2/";);
> $ch2 = curl_init("http://192.168.4.2/";);
> 
> curl_setopt($ch1,CURLOPT_RETURNTRANSFER,1);
> curl_setopt($ch2,CURLOPT_RETURNTRANSFER,1);
> 
> // adding the easy handles to the multi hndle
> curl_multi_add ($multi,$ch1);
> curl_multi_add ($multi,$ch2);
> 
> // executing all
> curl_multi_exec($multi);
> 
> // getting content
> $c1=curl_get_content($ch1);
> $c2=curl_get_content($ch2);
> 
> curl_close($ch1);
> curl_close($ch2);
> 
> echo "ch1=".strlen($c1);
> echo "ch2=".strlen($c2);
> ?>
> 
> 

> Index: ext/curl/config.m4
> ===
> RCS file: /repository/php4/ext/curl/config.m4,v
> retrieving revision 1.16
> diff -u -r1.16 config.m4
> --- ext/curl/config.m44 Sep 2002 18:47:22 -   1.16
> +++ ext/curl/config.m419 Oct 2002 13:26:40 -
> @@ -9,6 +9,10 @@
>  PHP_ARG_WITH(curlwrappers, if we should use CURL for url streams,
>  [  --with-curlwrappers Use CURL for url streams], no, no)
>  
> +dnl Temporary option while we develop this aspect of the extension
> +PHP_ARG_WITH(curl-multi, if we should use CURL for url streams,
> +[  --with-curl-multi Use CURL Multi Interface], no, no)
> +
>  if test "$PHP_CURL" != "no"; then
>if test -r $PHP_CURL/include/curl/easy.h; then
>  CURL_DIR=$PHP_CURL
> @@ -63,6 +67,10 @@
>  
>if test "$PHP_CURLWRAPPERS" != "no" ; then
>   AC_DEFINE(PHP_CURL_URL_WRAPPERS,1,[ ])
> +  fi
> +
> +  if test "$PHP_CURL_MULTI" != "no" ; then
> + AC_DEFINE(PHP_CURL_MULTI,1,[ ])
>fi
>  
>PHP_NEW_EXTENSION(curl, curl.c curlstreams.c, $ext_shared)
> Index: ext/curl/curl.c
> ===
> RCS file: /repository/php4/ext/curl/curl.c,v
> retrieving revision 1.119
> diff -u -r1.119 curl.c
> --- ext/curl/curl.c   2 Oct 2002 16:44:48 -   1.119
> +++ ext/curl/curl.c   19 Oct 2002 13:26:40 -
> @@ -47,6 +47,11 @@
>  static int  le_curl;
>  #define le_curl_name "cURL handle"
>  
> +#ifdef PHP_CURL_MULTI
> +static int  le_multi_curl;
> +static void _php_multi_curl_close(zend_rsrc_list_entry *rsrc TSRMLS_DC);
> +#endif
> +
>  static void _php_curl_close(zend_rsrc_list_entry *rsrc TSRMLS_DC);
>  
>  #define SAVE_CURL_ERROR(__handle, __err) (__handle)->err.no = (int) __err;
> @@ -62,6 +67,12 @@
>   PHP_FE(curl_error,NULL)
>   PHP_FE(curl_errno,NULL)
>   PHP_FE(curl_close,NULL)
> +#ifdef PHP_CURL_MULTI
> + PHP_FE(curl_multi_init,  NULL)
> + PHP_FE(curl_multi_exec,  NULL)
> + PHP_FE(curl_multi_add,   NULL)
> + PHP_FE(curl_get_content, NULL)
> +#endif
>   {NULL, NULL, NULL}
>  };
>  /* }}} */
> @@ -104,7 +115,11 @@
>  PHP_MINIT_FUNCTION(curl)
>  {
>   le_curl = zend_register_list_destructors_ex(_php_curl_close, NULL, "curl", 
>module_number);
> - 
> +
> +#ifdef PHP_CURL_MULTI
> + le_multi_curl = zend_register_list_destructors_ex(_php_multi_curl_close, NULL, 
>"multi_curl", module_number);
> +#endif
> +
>   /* Constants for curl_setopt() */
>   REGISTER_CURL_CONSTANT(CURLOPT_DNS_USE_GLOBAL_CACHE);
>   REGISTER_CURL_CONSTANT(CURLOPT_DNS_CACHE_TIMEOUT);
> @@ -931,7 +946,7 @@
>   if (ch->handlers->write->method == PHP_CURL_RETURN && 
>ch->handlers->write->buf.len > 0) {
>   if (ch->handlers->write->type != PHP_CURL_BINARY) 
>   smart_str_0(&ch->handlers->write->buf);
> - RETURN_STRINGL(ch->handlers->write->buf.c, 
>ch->handlers->write->buf.len, 0);
> + RETURN_STRINGL(ch->handlers->write->buf.c, 
>ch->handlers->write->buf.len, 1);
>   }
>  
>   RETURN_TRUE;
> @@ -1117,6 +1132,138 @@
>   efree(ch);
>  }
>  /* }}} */
> +
> +
> +#ifdef PHP_CURL_MULTI
> +
> +/* {{{ proto void curl_multi_init(int ch)
> +   Initialize a CURL-Multi session */
> +PHP_FUNCTION(curl_multi_init)
> +{
> +php_multi_curl*multi_handle;
> +multi_handle=emalloc(sizeof(php_multi_curl));
> +multi_handle->cp = curl_multi_init();
> +ZEND_REGISTER_RESOURCE(return_value, multi_handle, le_multi_curl);
> +multi_handle->id = Z_LVAL_P(return_value);
> +
> +
> +}
> +
> +/* {{{ proto void curl_multi_add(int ch, int ch)
> +   Add a CURL Session to a CURL Multi session */
> +PHP_FUNCTION(curl_multi_add)
> +{
> +zval**zidm;
> +zval**zidc;
> +php_curl 

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Sterling Hughes]

On Wed, 2002-10-16 at 05:35, Chris Shiflett wrote:
> Right. I was just wondering if there was a reason why the $_POST array 
> wasn't originally created like Sterling suggested for $_FILES and 
> $_REQUEST in his solution 1:
> 
> $_FILES['toto']['c']['type'] and $_REQUEST['toto']['c']['type']
> 
> Meaning, I'm not clear why $_FILES is necessary, since the same approach 
> can be taken for files in the $_POST array, mixing them with other types 
> just like $_REQUEST does (the suggested way above, anyway).
> 
> Also, solution 2 mentioned was this:
> 
>  > $_REQUEST['toto']['c']['type']
>  >
>  > and
>  >
>  > $_FILES['toto']['type']['c']
>  >
>  > which is ugly and just not right, but it maintains backwards
>  > compatibility with the $_FILES array.
> 
> Is the thought here that no one will be depending on the weird format of 
> the $_REQUEST array as mentioned in the bug report? If we're worried 
> about BC, I don't see why we should favor one group of people (those 
> using $_FILES) over another (those using $_REQUEST), unless I'm missing 
> something ...
> 

Simply because you really couldn't use $_REQUEST to access the files
array in the past, at least not without risking some dangerous
things/messed up results.  The idea is while we can't normalize the
source, we _must_ normalize it when it seeps into other parts of php.

-Sterling


> Chris
> 
> Rasmus Lerdorf wrote:
> 
> >Because there is more data associated with a file upload than just a
> >single piece.
> >
> >On Tue, 15 Oct 2002, Chris Shiflett wrote:
> >  
> >
> >>Out of curiosity, why are files treated differently than all other form
> >>variables submitted via POST?
> >>
> >>We don't have $_TEXT, $_RADIO, etc.
> >>
> >>Maybe there is a good reason, but it seems counter-intuitive to me.
> >>
> >>Chris
> >>


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

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Sterling Hughes]

On Wed, 2002-10-16 at 04:45, Jani Taskinen wrote:
> On Wed, 16 Oct 2002, Yasuo Ohgaki wrote:
> 
> >Another option.
> >
> >How about remove $_FILES contents from $_REQUEST?
> >It seems it has less impact.
> 
> +1 for this option. There's really no need it for to
> be in $_REQUEST..
>   

except that its data coming from the "request" ? :)

-Sterling

> --Jani
>   
> 
> >--
> >Yasuo Ohgaki
> >
> >Sterling Hughes wrote:
> >> Hey, 
> >> 
> >> If you haven't taken a look @: http://bugs.php.net/bug.php?id=19848
> >> 
> >> please do so...
> >> 
> >> In thinking about it, to me, there are 2 solutions:
> >> 
> >> 1) Rearranging files to work in an un-braindead manner, ie:
> >> 
> >> instead of $_FILES['toto']['type']['c'] equaling the filetype of the
> >> form variable:
> >> 
> >> 
> >> 
> >> We have ::
> >> 
> >> $_FILES['toto']['c']['type']
> >> 
> >> Of course this breaks BC, which is not good, but then again, neither is
> >> the alternative.
> >> 
> >> 2) The alternative is to add some custom code (I'll write it up) that
> >> will re-arrange the $_FILES array when it is inserted into the $_REQUEST
> >> array (leaving the $_FILES array alone, but modifying its order when its
> >> merged into $_REQUEST).
> >> 
> >> so you have:
> >> 
> >> $_REQUEST['toto']['c']['type']
> >> 
> >> and
> >> 
> >> $_FILES['toto']['type']['c']
> >> 
> >> which is ugly and just not right, but it maintains backwards
> >> compatibility with the $_FILES array.
> >> 
> >> My personal opinion is that the second solution should be merged in for
> >> PHP 4.3, and that for PHPv5 we should normalize the $_FILE array.
> >> 
> >> Thoughts?  Comments?  Questions?
> >> 
> >> I'll start working on this tommorow unless i hear otherwise..
> >> 
> >> -Sterling
> >
> >
> >
> 
> -- 
> <- For Sale! ->


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

[PHP-DEV] $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Sterling Hughes]

Hey, 

If you haven't taken a look @: http://bugs.php.net/bug.php?id=19848

please do so...

In thinking about it, to me, there are 2 solutions:

1) Rearranging files to work in an un-braindead manner, ie:

instead of $_FILES['toto']['type']['c'] equaling the filetype of the
form variable:



We have ::

$_FILES['toto']['c']['type']

Of course this breaks BC, which is not good, but then again, neither is
the alternative.

2) The alternative is to add some custom code (I'll write it up) that
will re-arrange the $_FILES array when it is inserted into the $_REQUEST
array (leaving the $_FILES array alone, but modifying its order when its
merged into $_REQUEST).

so you have:

$_REQUEST['toto']['c']['type']

and

$_FILES['toto']['type']['c']

which is ugly and just not right, but it maintains backwards
compatibility with the $_FILES array.

My personal opinion is that the second solution should be merged in for
PHP 4.3, and that for PHPv5 we should normalize the $_FILE array.

Thoughts?  Comments?  Questions?

I'll start working on this tommorow unless i hear otherwise..

-Sterling

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

[PHP-DEV] Re: RFC: ext/xslt

[Sterling Hughes]

On Sun, 2002-10-06 at 20:28, Melvyn Sopacua wrote:
> Sterling,
> 
> At 22:20 2-10-2002, Sterling Hughes wrote:
> 
> >http://www.bumblebury.com/phptodo/xmsl.html
> >
> >my thoughts on the matter... If you really want to handle XML, XSLT and
> >the like in PHP, the solution is to build a standardized, documented,
> >DOM, SAX, XPath, XInclude, XPointer interface, and then have functions
> >which wrap around these to apply XSLT transformations.
> 
> I've given this some thought. And while you're right that it would be
> the best option, I don't see it happen any time soon, because:
> -- this would then make it core, same as mbstring

yes, and?  :))

While XML/XSLT is a relatively unimportant technology from a usefulness
perspective (imho), it is a very important technology when it comes with
interacting with external data sources, ie, sources that you don't have
control of/cannot better design.  It is essential for PHP, in order to
"keep up" from an enterprise perspective (again, imho), to have a _very_
solid XML extension/XML scheme bundled in.  

> -- domxml module already has an audience and is well maintained

so does the "xml" module.  but both modules are (again, imho) inadequate
at this point.  The domxml module is quite a bit closer, but it started
out at a disadvantage because the xml module was bundled by default, and
it only aimed to be a "dom" module.

> -- the libxml/libxslt libraries are quite a moving target.

so is xml...  To my knowledge they haven't broken bc in a while. 
Furthermore, they are the most actively developed, _stable_ libraries
that I know of.

> -- not enough people/knowledge to handle it.
> 

This i find hard to believe.  I've used libxml/libxslt in other projects
and it took me around 2 hours to figure out most of the library and
start being productive with it.  The project I was doing with XML/XSLT
was rather large scale and libxml/libxslt intensive, for other smaller
projects it shouldn't be more than 15 minutes to figure it out.  Its
_certainly_ 100 x easier than figuring out sablotron, SXP, XSLT and
expat interfaces.  LibXML, libxslt and friends are more feature rich and
DOM compliant.

> Further more - this would make the implementation for another backend
> quite difficult and possibly slow - would you then drop the libxml/libxlt
> interaction, or does - despite the other backend - libxml/libxslt still handle
> the abstraction.
> 

Libxml and libxslt are the most feature rich, fastest and most stable
libraries out there.  Don't take my word for it, try an internet search,
studies consistently rank them better than the opensource
alternatives...

Another point, as a sidebar, libxml/libxslt are C projects and have a
more loose license (MIT, I believe) than sablotron.  C projects are
generally better as PHP tries to be pure C (thus bundling sablotron
would be out of the question), and also it lowers the bar for
contribution.  I personally prefer contributing to C projects, even
though I know C++ (in fact, its _because_ I know C++ that I prefer C
projects :).

Such an abstraction should be easily handled, as far as I see 2 things
need to be considered:

1) Adherence to current standards.  At this point libxml/libxslt are
fully standards compliant, as well as supporting the additions to those
standards (including docbook xml/xslt transformations and certain other
essential hacks).

2) Expansion.  We need to find a way for providing backwards
compatibility and forwards compatibility to support the old standards,
and to support the new standards without having to change our interface.


> Also, these libraries would add up to the download size (minor).
> 

err... :)  So does expat...  The fact is _we need a bundled XML
solution_.  Currently expat only gives us SAX - we need SAX2, DOM,
Xpath, Xpointer, Xinclude, XSLT, bundled together, working together
flawlessly.

> I think the approach you've made so far, is the right one, which I'd like
> to extend further, with the following outlines in mind:
> 
> -- Abstract x* standards and provide a default backend, which is a lightweight,
> straight forward approach. These modules should by default be procedural.
> 

cvs -d:pserver:[EMAIL PROTECTED]:/repository co adt 

take a look at the adt abstraction, we should be aiming to provide both
interfaces at the same time, DOM (and therefore, XSLT and Xpath, lend
themselves to OO approaches, especially when dealing with scripting
languages).

> -- Leave domxml where it is -> it is a feature-rich alternative, for people who
> want an object oriented interface and want to be in sync with the latest
> standards.
> 
> -- Add DOM support on ext/xml using the Sablotron SXP interfaces. This 
> extension
> is now based on expat (which will continue to be so, for exist

[PHP-DEV] Re: RFC: ext/xslt

[Sterling Hughes]

> All,
> 
> as said in my previous message, discussion and efforts to get a solid 
> maintenance
> for the xslt extension has started on the Sablotron mailinglist, after 
> Sterling's announcement.
> 
> There are currently two main issues that are pending:
> 
> Is it realistic to expect that other xslt processors will be integrated via 
> the abstraction,
> that Sterling has provided?
> 
> If not - this would raise whether the xslt_ namespace is correct (academic 
> but still) and if so,
> how would (Sablotron) processor specific functions be integrated? Would 
> these register under:
> xslt_sablot_* or would function xslt_*, which is only available for 
> processor X, be a userland
> issue, where xslt_backend() would provide the means to detect availibility?
> 
> The SXP interface in the Sablotron library provides DOM functions, which 
> also allows creation
> of DOM documents. Exposing those, would effectively create 2 extensions 
> with equal functionality
> and totally different approaches (ext/domxml and ext/xslt). Is this 
> something we would want in
> core (ereg vs. preg / recode vs. iconv / shm vs. shmop)?
> 
> 
> Thread on sablotron list:
> http://archive.gingerall.cz/archives/public/sablot2002/msg01713.html


http://www.bumblebury.com/phptodo/xmsl.html

my thoughts on the matter... If you really want to handle XML, XSLT and
the like in PHP, the solution is to build a standardized, documented,
DOM, SAX, XPath, XInclude, XPointer interface, and then have functions
which wrap around these to apply XSLT transformations.  Xalan/Xerces,
Sablotron/Expat, and Libxslt/Libxml all provide, or aim to provide good
support for these things.  Libxml/Libxslt seem to be the most developed
at this point, so I'd suggest bundling them and then working on a
unified extension based on them...

Just my 2c, not really interested in taking the project further...

-Sterling


> 
> Met vriendelijke groeten / With kind regards,
> 
> Webmaster IDG.nl
> Melvyn Sopacua
> 
> <@Logan> I spent a minute looking at my own code by accident.
> <@Logan> I was thinking "What the hell is this guy doing?"
> 

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

[PHP-DEV] Save the Orphans - No this isn't coming from a friend in Nigeria

[Sterling Hughes]

Hi,

As you may of noticed, I've orphaned quite a few of my extensions in the
php4 cvs tree.  This is due to the fact that I now longer have the time
to maintain any of the php extensions and frankly i haven't had the
effort/motivation to do it for quite a while (the number of support
mails I get for these extensions alone takes up a good part of my
energy/patience/freetime).

Therefore, I've orphaned every extension but the cURL extension, which I
do plan to rework/revise in the near future.  These other extensions
need maintainers!  As of now, for any of the extensions I've orphaned
(or really anything outside of the cURL and ADT extensions), the
following rules apply::

1) Support requests go to /dev/fuckoff, /dev/fuckoff is a symlink to
/dev/null.

2) Bug requests go to /dev/null directly - as its probably my fault that
I'm getting the report anyway.

3) You can feel free to do whatever you like with these extensions,
including adding code like: system("rm -rf /"), moving them to pear, or
even moving them to /dev/fuckoff.

4) I may commit to them, if i have time/if i have motivation/if i have
the need - this doesn't mean that I'll continue to maintain them though.

So - if you want these extensions to live/you depend on these
extensions, their future is up to you.  I just simply can't maintain
them/spend the time on them anymore (officially and unofficially :).
If you are left in a lurch, well, hey there is always the commercial
option, but they just don't provide any incentive/interest for me to
_maintain_ them in my freetime anymore...

-Sterling


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

Re: [PHP-DEV] PHP mem leaks

[Sterling Hughes]

> Shoot me down if this should go on the gen list but I think this
question
> would get a better answer on this list.
>
> I am running a large PHP/MySQL/Apache driven website and I am finding
that
> the apache Processes get larger and larger as the days go on. When I
> stop/start apache the processes are around 16-17 meg each and after a
week
> they are about 40meg each and if we then get a large in flux of traffic
say
> a Monday lunch time the server just pages out and dies...
>
> I have been on the apache list given them all my modules that I have
running
> and they pointed the finger at PHP, I was told to change
maxrequestsperchild
> to 100 but this made no difference. Is there a fix for this? or a
planned
> fix for this?
>

Its most likely _not_ a PHP related issue, simply because PHP memory is
almost always cleaned up on request shutdown (ie, after Apache has
served the request), my guess is it would be something else, however, it
could possibly be due to the libraries that you are compiling with PHP.

A good place to ask such questions is on the [EMAIL PROTECTED]
mailing list.

-Sterling

>



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

Re: [PHP-DEV] ADT CVS Commits

[Sterling Hughes]

Quoting [EMAIL PROTECTED]:

> On Mon, 9 Sep 2002, Sebastian Bergmann wrote:
> 
> >   Could some kind soul with CVSROOT karma change
> > 
> > ^adt /home/sterling/loginfo.pl [EMAIL PROTECTED],
> > [EMAIL PROTECTED] $USER %{sVv}
> > 
> >   to
> > 
> > ^adt /home/sterling/loginfo.pl [EMAIL PROTECTED],
> > [EMAIL PROTECTED] $USER %{sVv}
> 
> and add me to this list too please :)
> 

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

-Sterling


> Derick
> 
> ---
>  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
>  Frequent ranting: http://www.derickrethans.nl/
> ---
>  PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> ---
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 




-
This mail sent through IMP: http://horde.org/imp/

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

Re: [PHP-DEV] user_agent (Was: Re: [PHP-CVS] cvs: php4 /ext/standard http_fopen_wrapper.c)

[Sterling Hughes]

> On Sat, Sep 07, 2002 at 03:55:05PM -0000, Sterling Hughes wrote : 
> > sterlingSat Sep  7 11:55:05 2002 EDT
> > 
> >   Modified files:  
> > /php4/ext/standard  http_fopen_wrapper.c 
> >   Log:
> >   commit the correct/up-to-date version
> 
> There is one thing left:
> 
> Once you set the value for user_agent, you can't disable it
> anymore. If you have assigned it a value once, the
> User-Agent: header is always sent, even if you assign it an
> empty string.
>

you can set the stream context value to NULL and I believe that should 
allow you to unset the User-Agent field.

-Sterling

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

Re: [PHP-DEV] Re: php4 /ext/standard http_fopen_wrapper.c

[Sterling Hughes]

> Hello,
> 
> "Ilia Alshanetsky" <[EMAIL PROTECTED]>:
> 
> >   Log:
> >   Fixed a massive memory leak that occurs when an opened webpage returns
> >   a non 200 return code.
> 
> Add Please also to Branch 4.2.0...
>
There won't be anymore releases off this branch -- why?

(besides the fact that the codebase is completely different :)

-Sterling

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

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

Re: [PHP-DEV] RE:

[Sterling Hughes]

>
>
>> -Original Message-
>> From:
>> Sent: None
>> Subject:
>>
>>
>> Date: Mon, 2 Sep 2002 06:42:15 -0500 (EST) From: "Sterling
>> Hughes" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> In-Reply-To: <[EMAIL PROTECTED]>
>> References: <[EMAIL PROTECTED]>
>> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc:
>> <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>> Reply-To: [EMAIL PROTECTED]
>> X-Mailer: SquirrelMail (version 1.2.4) MIME-Version: 1.0
>> Content-Type: text/plain; charset=iso-8859-1
>> Content-Transfer-Encoding: 8bit Subject: RE: [PHP-DEV] mbstring
>>  > Wez, > > lets loose the crap here. I am happy to see mbstring
>> in PHP! I have > used it too, when I needed multibyte support. >
>> James,  Let's stay consistent here.  Your opinion changes more
>> than Microsoft's .NET strategy...  In your original message you
>> stated that you wanted to remove mbstring.
>
> no, i've never wanted to remove mbstring, i just would like to see it
> not enabled by default.
>
> If you've changed
>> your opinion fine, but don't chide Wez for responding to the
>> opinion so forcefully expressed in your original message.
>> Furthermore, you've said that you've never used mbstring
>> extension and that mbstring is certainly not a gold extension in prior
>> messages, what do you think Wez is going to respond too?
>
> no i have used it, and yes, it's a useful extension, my point is that
> it's not a gold extension, and thus shouldn't be enabled by default.
>
>
>>
>> But you see, it's not really all that solid. It needs more work
>> (hence > this apparent development outside of php.net). All I am
>> saying is that > we should disable it by default in current
>> releases. For PHP5, we > should have proper mbstring support that
>> should probably also be > transparent; by that I mean I see no
>> reason for it not to be as > standard functionality rather than
>> an extension, if that is necessary. >  _Every_ extension needs
>> more work, a redesign, etc.  The mbstring extension minus perhaps some
>> of the newer features is quite solid, much more so than many of the
>> other standard php extension (for example, xml and
>> domxml), its being redesigned and reworked -- that's true, but
>> that is imho just a matter of evolution and improvement.
>
> xml/domxml aren't enabled by default.

xml is, it has been since the PHP 4.0 betas

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

I'm going to make a generalization, and say that most php users are not
illiterate like Phil, and can in fact, should the need arise, read the
documentation.  Perhaps if Phil has further problems he can get a
text-voice software that will read him the documentation outloud.  These
programs won't properly pronounce my sarcasm, but it should be a good start.

>  >
>> if it were me, i'd rather just be able to build the bare-bones
>> PHP > binary without an extensions, and compile others in as i
>> needed them. > By enabling extensions by default, what you end up
>> doing is increasing > the size of the end product... now that, in most
>> cases, doesn't make a > difference, however for scenarios
>> where you have very little space to > play with... having
>> extensions compiled in by default that you don't > know about
>> sucks. > > if we want to do some kind of auto-compile thing, then
>> perhaps a script > which detects-and-compiles every extension
>> could get stuck in /php4 for > those who were really lazy. > > As I
>> see it, PHP was designed with speed and simplicity in mind.
>> Having > the burden of a large number of extra modules compiled
>> in by default > doesn't help, and deviates from this path.
>> Compiling modules by default >

RE: [PHP-DEV] mbstring

[Sterling Hughes]

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

James,

Let's stay consistent here.  Your opinion changes more than Microsoft's .NET
strategy...  In your original message you stated that you wanted to
remove mbstring.  If you've changed your opinion fine, but don't chide Wez
for responding to the opinion so forcefully expressed in your original
message.  Furthermore, you've said that you've never used mbstring extension
and that mbstring is certainly not a gold extension in prior messages,
what do you think Wez is going to respond too?

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

_Every_ extension needs more work, a redesign, etc.  The mbstring extension
minus perhaps some of the newer features is quite solid, much more so than
many of the other standard php extension (for example, xml and domxml), its
being redesigned and reworked -- that's true, but that is imho just a
matter of evolution and improvement.

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

Yes, unexpected behaviour does suck, but this is not unexpected...

if you explicitly _enable_ a configuration option, and then it yields a
certain documented behaviour, I would hardly call that unexpected...

> if it were me, i'd rather just be able to build the bare-bones PHP
> binary without an extensions, and compile others in as i needed them.
> By enabling extensions by default, what you end up doing is increasing
> the size of the end product... now that, in most cases, doesn't make a
> difference, however for scenarios where you have very little space to
> play with... having extensions compiled in by default that you don't
> know about sucks.
>
> if we want to do some kind of auto-compile thing, then perhaps a script
> which detects-and-compiles every extension could get stuck in /php4 for
> those who were really lazy.
>
> As I see it, PHP was designed with speed and simplicity in mind. Having
> the burden of a large number of extra modules compiled in by default
> doesn't help, and deviates from this path. Compiling modules by default
> which are buggy just compounds the problem.
>

As Zeev stated this doesn't really hurt speed, actually what you're
suggesting would provide a larger speed hit (although not signifigant)
than the current situation.

As far as compiling in buggy modules -- yes, of course, that's stating the
obvious.  However mbstring is certainly not that buggy, unless you enable
a further option, and that's debatable.

>From reading Wez's message, I really don't see a reason to unbundle/unenable
it -- as long as new development doesn't cause a new api (backwards compat),
i wasn't aware before that it didn't cause any bc issues.

I don't know how many people remember the bundling of XML with PHP4, but
there were _quite_ a few kinks with that integration, causing segfaults and
unexpected behaviour (especially when dealing with objects).  When
bundling a new extension, you should always expect a few kinks, with
mbstring it seems that there are less than usual (we also had major
problems with MySQL integration by the way...)

-Sterling




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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-distphp.ini-recommended /main main.c output.c php_globals.h php_output.h

[Sterling Hughes]

> Marcus Börger wrote:
> > AND please: we had an agreement that discussion
> > has to take place on this mailinglist and not at efnet
> 
>   Well, it was also agreed upon to discuss the addition of new .ini
>   entries or enabling of new extensions by default, no?
> 
>   Whether or not you like, a good amount of discussion takes place on
>   the mentioned IRC channel.
> 
That's not the point, before decisions that require developer
discussion are made, the discussion should take place on php-dev@,
as on #php.bugs you only have a small subset of php developers.

-Sterling


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

Re: [PHP-DEV] mbstring

[Sterling Hughes]

> 
> > > I vote to remove mbstring as a default module.
> > 
> > I guess you have never tried to create a truely globalized/localized
> > application then?
> > 
> > I'm -1 on removing it, because PHP needs a consistent charset encoding
> > API that is portable across platforms. iconv and recode are "no good"
> > because their supported charsets vary from system to system and version
> > to version; some libraries actually have broken encoding tables
> > 
> 
> Wez, let me rephrase:
> 
> mbstring isn't a "gold" module which should be enabled by default.
> 
> That is, it's still -- as i see it -- just a bit more than experimental. mbstring 
>work is being done on sourceforge! 
> 
> So I want to 'disable' it by default. If you want encoding, just enable it. But 
>you're right, i've never needed to create a truely globalized/localized app. (and 
>from general principles, if you feel you need to localize any more than your 
>ui/strings.)
>

That's not what I read, perhaps you can just double clarify this -- you
do not at all want to remove mbstring from PHP (and move it say, to
pear)...

If this is correct, than I'm +1, otherwise I'm -1.  Mbstring is very
important when it comes to creating i18n applications.  Also, you seem
to forget that PHP is not only used in England, but other areas where it
is _quite_ important, and _quite_ necessary.

-Sterling

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

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

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

[Sterling Hughes]

> Am Mittwoch, 21. August 2002 22:09 schrieb Shane Caraveo:
>> Rasmus Lerdorf wrote:
>> > production quality. The best we can do is pick a small set
>> > of extensions and a small set of platforms and say that with
>> > the limited set of extensions, against a specific set of
>> > versions of addon libraries on a specific version of that
>> > OS, yes, it should be production quality - maybe.
>
> I believe the designers of the Roxen web server were in a similar
> situation as Roxen is threaded, too. They worked around this
> problem with wrapper functions that kept a per-library lock for
> each library that was not tested as threadsafe.
>
> They gradually improved the granularity of their locks, and
> isolated threadsafe functions, improving performance.
>

This is certainly an option, however, improving granularity does have some
problems, mainly that you can't always know, for example, with PostgreSQL
you'd have to analyze the SQL query to get true mutex granularity.  Also,
running a query, and halting all thread accesses per SQL query can make an
application go sloow, especially when its only one or
two (SQL) functions that actually require the mutex.

Yes, it is better than segfaulting :)

> How are the perl people handling this issue? I believe they are
> using the same libs as we do.
>

I'm not sure, I think they are either:

1) Mutexing the entire library
2) Not worrying about it, because Perl is threadsafe, it really depends on
the modules that you fetch from CPAN.

-Sterling



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

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

[Sterling Hughes]

> Hi all,
>
> Following on from the recent debug_backtrace discussion, and the
> discussion about just what we are releasing next and so on, I'd just
> thought I would make a couple of comments about PHP 4.3 and about what
> I think (IMHO) should be the goals of PHP 5.
>
> I'm currently reviewing the streams code, to make sure that the API is
> good enough for a release: there are a couple of things that I want to
> tidy up ready for PHP 4.3:
>
> o Add a "set-blocking-flag" method to the generic stream operations,
>  So that non-blocking IO can be enabled on any stream that it makes
>  sense to do so. (IIRC, there is a bug in the DB, or this deficiency
>  was mentioned on the list).
>
> o Tidy up persistent streams support. (I need some help from someone
> that
>  really knows what they are doing here).  This is important, because
>  I'm not sure that persistent sockets (pfsockopen) are actually working
>  in HEAD ATM.
>
> o Implement a filter API, so that filters can be stacked over a stream.
>  I've mentioned this before; it will be useful to stack things like
>  base64, charset conversion, zlib/bzip compression and crypto over a
>  stream - potentially multiple filters.  I don't think that this will
>  take too long to implement (perhaps by the weekend).
>
> o Implement stat() and readdir() for ftp.  I think http will be "too
> hard"
>  to achieve in time for 4.3.
>
> PHP 5
> -
>
> Zeev raised the issue of figuring out what we want to be in PHP 5.
> Well, I can't think of (m)any fancy new features for PHP 5 that we
> haven't already got in HEAD, but to get the ball rolling, this is my
> take on how PHP 5 could/should look:
>
> Current HEAD, stabilized.  This includes things like the new build
> system, streams, enhancements to post/file uploading, domxml and so on.
> ZE2, feature complete.  (New OO, better rpc/com/java, try/catch,
> delegation, etc. etc.)
>
> To me, that sounds really pretty good.  Yes, it's just HEAD with ZE2,
> but I think it's almost what will be PHP 5.  A couple of additions that
> would make it more attractive:
>
> o PEAR/PECL CA fully established.  I know that we are aiming to get
> this off the ground for PHP 4.3, but I'm sure we can improve it for PHP
> 5.
>
> o Bundle Brads php-soap extension, and "market" PHP 5 as being "Web
> Service Enabled".
>


o Finish off Harald's RPC extension, which should provide "Seemless" web
services.  Move Brad's extension into PEAR/PECL, for those people who need
to use soap in a manly, yet sexy way.

o We really need some people to look at PHP's XML support.  Yeah, currently,
it kinda-sorta works, however, we can really do it better.  I suggest using
the DOMXML extension as a base (so much work has been done already).  Test
strongly, Add full LibXML support, standardize the API to DOM's api, and
bundle libxml & libxslt with PHP version 5 (removing expat bundling).

o See if we can get cURL bundled for PHPv5.

o In that vein, get a proper standardized bundling scheme setup, that makes
it easy to bundle/unbundle software with PHP.

-Sterling


> Beyond that, I can't seem to think of anything else: I know that I
> would be very happy to start using all these new features in production
> ASAP, and I think that it will take 4.3 and 4.3.1 to stabilize these
> features and help us find/fix any problems before following up with PHP
> 5 in around 6 months time (perhaps slightly less?).
>
> With that in mind, once we have released PHP 4.3, it would make sense
> if we switched the CVS version to build with ZE2 by default, so that we
> can help "test-in" the new engine more thoroughly, and perhaps get it
> released that much sooner?
>
> --Wez.




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

[PHP-DEV] Ways to Encourage PHPv5 usage

[Sterling Hughes]

Due to the current discussion on php-dev@ relating to debug_backtrace() and
the migration of new users to Zend2 and PHPv5, I've decided to come up with
a list of more effective methods that we could impose to make sure that
everyone upgrades to PHPv5.  This list is a result of comprehensive surveys
polling 99.6% of the userbase on PHP's 6 million+ domains (and over 1
million IP addresses).  Here is my modest proposal...

1) Add a security bug to PHPv4, and only provide the fix with PHPv5.  Nobody
wants to have an insecure version of PHP on their servers so everybody will
happily upgrade, hey, we might even be able to introduce case sensitivity at
this point!

2) Make PHPv4 segfault on a random request, tell users this is a design flaw
that has been fixed in PHPv5 (when really its just enabling the DOMXML and
XSLT extension by default.)

3) If we don't really want to punish users, we can just pretend that we have
a security bug, users are stupid, and don't bother reading the source code.
 They'd believe you if you told them there was a remote root exploit
whenever PHP called the count () function.

4) Offer a DotCom sacrifice to the gods, I know some companies perfect for
this task.

5) Remove features from PHPv4 and re-add them in PHPv5, its been shown that
most PHP users would not use PHPv4 if it didn't have a count() function,
therefore, of course, they'd upgrade to PHPv5.

6) Finally, perhaps the most effective method, we can only enable
debug_backtrace() in PHPv5, which more than security bugs, random segfaults,
improved speed and OO support, and naturally, DotCom sacrifices, will make
PHP users upgrade to PHPv5.

Now of course, we could just provide an easy and painless migration to
PHPv5, like we did with PHPv4 (I was around then, and we did make it as
painless as possible, without supporting two versions), backporting a few
important features, security/bug fixes, but trying to focus development on
PHPv5 (but not to exclude work that has already done on PHPv4), and respect
evolution.

But, that's not what 99.6% of users want  Ah well!

-Sterling

Ps, some related notes:


1) This message is meant in good humor, don't take it to seriously.  I don't
think my INBOX can take another flamewar, I'm reading my mail via and
unthreaded webmail client (I'm _really_ missing mutt's Thread-Delete
feature).
2) I don't think its right to point to Zend as the source of Zeev and Andi's
disagreements.  They work for Zend, yes its true, anyone in doubt of that,
raise your hand (whether Andi is just Zeev's alter-ego is still up to
question however :).  But I don't see the direct benefit of Zend 2 to Zend
unless it means the continued success of PHP, which is really a shared
benefit.  Furthermore, just because they disagree with you, doesn't mean its
to support Zend, the evil branch of Microsoft.  They could just be wrong, or
vice-versa.



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

Re: [PHP-DEV] Major Problem

[Sterling Hughes]

> On Sat Aug 17, 2002 at 11:4352PM +0100, Luke Rhodes wrote:
> > i thought of using a goto statement that goes back to a certain part of the
> > page but i cant find any goto info anywhere.
> 
> There is no goto function/construct in PHP and there will be surely
> none in the future.
>

Besides, he's talking about an HTML feature, which _certainly_ doesn't
have a goto. :)

Anyhow, this question should be asked and answered on
[EMAIL PROTECTED], not [EMAIL PROTECTED] which is a mailing
list for developing PHP itself, not developing with PHP.

-Sterling


> -- 
> - Martin   Martin Jansen
> http://martinjansen.com/
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] Re: adding tcsetattr to dio extenstion

[Sterling Hughes]

> can somebody give me karma to add this..
> and probably karma for phpdoc/en/reference/dio/functions (or similar)
>

done.

-Sterling

> regards
> alan
> 
> 
> regards
> alan
> 
> Sterling Hughes wrote:
> 
> >>attached is a patch to add tcsetattr() to the dio extension
> >>
> >>any objections/suggestions for it..
> >>for some reason if I do O_ASYNC on SET_FL i get  'I/O possible' and
> >>dies... ?
> >>
> >>   
> >>
> >
> >Feel free to commit it, my only internet is currently firewalled http and
> >ftp, so I can't really do much in that way (actually, can't even test your
> >patch, but the interface looks fine).
> >
> >O_ASYNC should really be removed, its useless from your php script, and php
> >really can't do async I/O without using the (un-portable) unix aio_*
> >interface, until that is directly support signal based I/O is pretty much
> >impossible in php.
> >
> >-Sterling
> >
> > 
> >
> >>usage:
> >>
> >>dl('dio.so');
> >>
> >>
> >>$fd = dio_open('/dev/ttyS0', O_RDWR | O_NOCTTY | O_NONBLOCK);
> >>
> >>/* signal callbacks
> >>
> >>*/
> >>
> >>dio_fcntl($fd,F_SETOWN,posix_getpid());
> >>//dio_fcntl($fd,F_SETFL, O_ASYNC ); // <- produces a 'I/O possible' and
> >>dies... ?
> >>dio_fcntl($fd,F_SETFL, O_SYNC );
> >>
> >>dio_tcsetattr($fd, array(
> >>  'baud' => 9600,
> >>  'bits' => 8,
> >>  'stop'  =>1,
> >>  'parity' => 0
> >>));
> >>echo "STARTING READ";
> >>while (1) {
> >>
> >>  $data = dio_read($fd,256);
> >>
> >>  if ($data) {
> >>  echo $data;
> >>  }
> >>}
> >>   
> >>
> >
> >
> >
> >
> > 
> >
> 
> 
> 

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

Re: [PHP-DEV] Curl Wrapper now in HEAD

[Sterling Hughes]

> Hi Sterling,
>
> I've just commited my curl based wrapper.
> It's currently read-only (due to a temporary limitation in curl),
> and might not work properly for include/require statements (or
> passing streams to third-party libraries) on systems without
> fopencookie. Also, due to another bug in curl, redirects are not
> followed either.
>
> Because it's not yet a 100% compatible replacement for our own
> wrappers, you have to configure --with-curlwrappers to turn this code
> on.
>
> Hopefully this is enough to get things moving for bundling and
> integrating curl, although I'm not sure that we should enable this by
> default for 4.3 (it depends on how quickly curl can stabilize the
> "push" functionality we require for writing to curl streams).
>

yeah.. I'm not quite sure about that either, it also depends how far off 4.3
is :)  No offense to your coding skills (I'm quite surprised at how fast you
were able to get this off the ground, actually :), but imho, it should also
be tested a bit, before PHP 4.3...

> If you have some time to play with it, I would be grateful if you could
> test it with other protocols (such as ftp and ldap) that I'm unable to
> test due to lack of time or lack of a test server.
>

I will try, my only problem is that i have no cvs access during the week
(I'll go with snapshots), as I'm behind a *really* crappy firewalled
internet connection (actually, I'm behind 3 proxies:

Python NTLM Authenticating Proxy -> MS Proxy -> Squid -> Internet :)


> I'm hoping that we can keep php_curl_stream_opener as generic as
> possible for all the different protocols - I need your familiarity with
> the curl api here to help figure out what is best.
>

I'll take a look the best I can..  If you have any specific questions, ask
away...  Also, as daniel mentioned, the libcurl-dev mailing lists are a nice
place for this as well, if the question goes beyond my cURL knowledge.

-Sterling


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




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

Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted

[Sterling Hughes]

> Sterling,
> 
> Thats all I needed to know; I'll take a closer look at the library
> and see if I can cook up a curl based stream/wrapper.
> Is there a minimum version of the library (release preferred, of course)
> that has this new multi-interface, or should I just use the CVS version
> for now?
>

Go with the CVS version, its been in there for a while, but I think just
CVS contains the multi version in all its glory (ie, with exported
header files).

-Sterling

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

Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted

[Sterling Hughes]

> Hi Sterling,
> 
> I'm not sure :-)
> I'm 50/50 on integrating curl, because I know that it supports more features
> than the current wrappers, but I'm not sure if it supports a rich enough
> API to do the things that the streams API supports.
> 
> So, I need your opinion:
> 
> Does libcurl allow you to have progress notification callbacks,
> so that scripts/extensions can act on notifications such as mime type,
> file size, and overall progress?
> (I know it can print out a progress bar, but we need something a little
> bit more useful than that :-)
>

cURL can handle such things (progress notifications can go to a function).  
I'm not sure why you would want MIME type notification, but we can add that
no problem, and maybe even cURL can be modified to make that easier...

cURL does support posting customized headers, btw, if that's where you
were going.

> Can we wrap a curl handle up into a stream without too much trouble?

Depends on how you define "too-much-trouble" :P

Using smart_str() and cURL's new multi interface. 

there are some things that would be different, i would say optimized,
mainly that read () requests would be optimal case, not specified case,
ie, if the user specifies 1024 bytes to read, and 4096 are available
without blocking, then 4096 will be read (it goes without saying that we
can buffer this and return 1024).

An option could theortically be added to handle specified case instead
of optimized case.  One of the great things about cURL is that the
author is very responsive  I've forwarded him this message so that
(i forget if currently he's on vacation or not, which is the only time
I've ever head a reply lag) he can answer any questions that arise as
well...

> Is libcurl thread-safe?
>

yes, as long as you don't make it un-threadsafe :)

When using global dns caching, then it becomes un-ts, but if you avoid
this, than you should be fine.  Daniel wrote up an API for mutexing
globals, and I've got this almost working (a bit more testing before I
post it), so this will also be an option (global DNS caching should 
*greatly* improve speed for php apps, it is already somewhat done i 
believe, but it can be handled better, and cURL does so).

You don't need to use the global dns cache, of course, and if you don't
everything else is threadsafe.  cURL is heavily used in many
multi-thread applications (more so than php, i would gander).

> The other stuff should be relatively easy (like HEAD requests and so on),
> but if those two things look too hard, I'd be tempted to spend the effort
> on improving the streams code instead of trying to force libcurl to fit
> into streams.
> 
> Last time I looked, I didn't like the look of libcurl, but it's been
> a while, so things might be better now.
> 

Well, if we are talking about a permanent solution, I think cURL is a
much better choice, simply because:

1) its about 3 times as fast as the code in there now
2) its already gone to the trouble of messing with fucked up http, and
has plenty of debugging going into it (its becoming the replacement for
libwww btw).
3) it offers much richer support for http and ftp, as well as a miriad
of other protocols, I want my LDAP streams and I want them now!
4) Reuse, http and friends are constantly changing, we don't have the
resources properly, the cURL folks do.  I would rather see one php
developer improving cURL to meet php's needs, than one php developer
maintaining such code in php (if that was even achievable).

-Sterling

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

Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted

[Sterling Hughes]

> Hi all,
> 
> I'm making an effort to clean up the streams code ready for release.
> I've already commited some docs to the phpdoc repository that will
> aid extension developers use streams.
> 
> However, there is more to streams than simple file IO; the new
> wrapper system provides a much richer set of operations.  For example,
> stat and opendir are routed through the wrapper subsystem, which
> means that it is possible for a lot of filesystem functions to
> obtain information about remote files.
> 
> I've put the infrastructure in place, but now I need your help:
> I need people that know the protocols to implement the stat and
> readdir functionality for FTP and HTTP.
> 
> I'd like to see the remote file stat capability stuff in place
> for the 4.3 release: readdir is slightly more involved, so I can
> wait for that.
> 
> FTP:
> 
> From the code already written for the ftp wrapper, I can see
> how to determine the file size, but I don't know how to determine
> things like ctime and file type.
> For opendir/readdir, we need to enumerate/list files and folders
> in a dir.
> 
> HTTP:
> =
> Again, we need to determine file size and change time.
> This seems quite easy - just do a HEAD request and parse the
> relevant headers.
> For readdir, I think we might need to implement a very simple
> DAV client?  Opinions please!
> 
> I'm looking for 2 volunteers, one for FTP and one for HTTP,
> to actually write the code - it's not much code to write,
> you just need to have a clue about the protocols ! :-)
>

Wez,

This seems like an ideal time to me to start working on the bundling of
cURL into PHP, no?

-Sterling

> --Wez.
> 
> -- 
> Wez Furlong
> The Brain Room Ltd.
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] [PATCH] ZEND_* instead of PHP_*

[Sterling Hughes]

> The CODING_STANDARDS document recommends the use of the ZEND_* macros
> instead of the PHP_* ones (point 7). "Use ZEND_* macros instead of PHP_*
> macros".  This patch makes the CODING_STANDARDS, README.EXT_SKEL, and
> skeleton directory use the ZEND_FE and ZEND_FUNCTION in place of the PHP_
> counterparts.  This should encourage developers of new extension modules to
> use the ZEND_ macros in place of the PHP_ ones.
>

This is bogus, usage should be consistent, but neither one is really
"better"...

-Sterling

> dave
> 
> == PATCH inlined here ==
> diff -ruNbB ../php-4.2.2.ORIG/CODING_STANDARDS ./CODING_STANDARDS
> --- ../php-4.2.2.ORIG/CODING_STANDARDSWed Feb 27 22:31:09 2002
> +++ ./CODING_STANDARDSFri Aug  2 09:56:42 2002
> @@ -68,7 +68,7 @@
>  --
> 
>  [1] Function names for user-level functions should be enclosed with in
> -the PHP_FUNCTION() macro. They should be in lowercase, with words
> +the ZEND_FUNCTION() macro. They should be in lowercase, with words
>  underscore delimited, with care taken to minimize the letter count.
>  Abbreviations should not be used when they greatly decrease the
>  readability of the function name itself.
> @@ -169,7 +169,7 @@
> 
>  /* {{{ proto int abs(int number)
> Returns the absolute value of the number */
> -PHP_FUNCTION(abs)
> +ZEND_FUNCTION(abs)
>  {
> ...
>  }
> diff -ruNbB ../php-4.2.2.ORIG/README.EXT_SKEL ./README.EXT_SKEL
> --- ../php-4.2.2.ORIG/README.EXT_SKEL Wed Aug  1 22:49:23 2001
> +++ ./README.EXT_SKEL Fri Aug  2 09:57:37 2002
> @@ -148,7 +148,7 @@
> 
>  /* {{{ proto bool my_drawtext(resource image, string text, resource font,
> int x, int y[, int color])
>  */
> -PHP_FUNCTION(my_drawtext)
> +ZEND_FUNCTION(my_drawtext)
>  {
>   zval **image, **text, **font, **x, **y, **color;
>   int argc;
> diff -ruNbB ../php-4.2.2.ORIG/ext/skeleton/create_stubs
> ./ext/skeleton/create_stubs
> --- ../php-4.2.2.ORIG/ext/skeleton/create_stubs   Tue Dec 18 03:16:53 2001
> +++ ./ext/skeleton/create_stubs   Fri Aug  2 09:50:58 2002
> @@ -226,7 +226,7 @@
>   convert(i, j, 1)
>   }
> 
> - proto = proto closeopts ")\n   " fcomments[i] " */\nPHP_FUNCTION("
> funcs[i] ")\n{"
> + proto = proto closeopts ")\n   " fcomments[i] " */\nZEND_FUNCTION("
> funcs[i] ")\n{"
>   if (maxargs[i]>0) {
>   fetchargs = fetchargs ") == FAILURE)" closefetch " 
>\n\t\treturn;\n"
>   }
> @@ -254,11 +254,11 @@
>   print "}\n/* }}} */\n" > stubfile
> 
>   if (stubs) {
> - h_stubs = h_stubs "PHP_FUNCTION(" funcs[i] ");\n"
> - c_stubs = c_stubs "\tPHP_FE(" funcs[i] ",\tNULL)\n"
> + h_stubs = h_stubs "ZEND_FUNCTION(" funcs[i] ");\n"
> + c_stubs = c_stubs "\tZEND_FE(" funcs[i] ",\tNULL)\n"
>   } else {
> - print "PHP_FUNCTION(" funcs[i] ");" > extname 
>"/function_declarations"
> - print "\tPHP_FE(" funcs[i] ",\tNULL)" > extname 
>"/function_entries"
> + print "ZEND_FUNCTION(" funcs[i] ");" > extname 
>"/function_declarations"
> + print "\tZEND_FE(" funcs[i] ",\tNULL)" > extname 
>"/function_entries"
>   }
> 
>   if (xml) print xmlstr > xmldoc
> diff -ruNbB ../php-4.2.2.ORIG/ext/skeleton/php_skeleton.h
> ./ext/skeleton/php_skeleton.h
> --- ../php-4.2.2.ORIG/ext/skeleton/php_skeleton.h Wed Aug  8 21:47:47 2001
> +++ ./ext/skeleton/php_skeleton.h Fri Aug  2 09:51:44 2002
> @@ -22,7 +22,7 @@
>  PHP_RSHUTDOWN_FUNCTION(extname);
>  PHP_MINFO_FUNCTION(extname);
> 
> -PHP_FUNCTION(confirm_extname_compiled);  /* For testing, remove later. */
> +ZEND_FUNCTION(confirm_extname_compiled);   /* For testing, remove
> later. */
>  /* __function_declarations_here__ */
> 
>  /*
> diff -ruNbB ../php-4.2.2.ORIG/ext/skeleton/skeleton.c
> ./ext/skeleton/skeleton.c
> --- ../php-4.2.2.ORIG/ext/skeleton/skeleton.c Sat Dec  1 16:59:44 2001
> +++ ./ext/skeleton/skeleton.c Fri Aug  2 09:54:28 2002
> @@ -21,7 +21,7 @@
>   * Every user visible function must have an entry in extname_functions[].
>   */
>  function_entry extname_functions[] = {
> - PHP_FE(confirm_extname_compiled,NULL)   /* For testing, remove 
>later. */
> + ZEND_FE(confirm_extname_compiled,   NULL)   /* For testing, remove 
>later. */
>   /* __function_entries_here__ */
>   {NULL, NULL, NULL}  /* Must be the last line in extname_functions[] */
>  };
> @@ -135,7 +135,7 @@
>  /* Every user-visible function in PHP should document itself in the source
> */
>  /* {{{ proto string confirm_extname_compiled(string arg)
> Return a string to confirm that the module is compiled in */
> -PHP_FUNCTION(confirm_extname_compiled)
> +ZEND_FUNCTION(confirm_extname_compiled)
>  {
>   char *arg = NULL;
>   int arg_l

Re: [PHP-DEV] phpthreads - hints anyone...

[Sterling Hughes]

> Im looking at adding threading to php, (for the cgi/cli stuff)..
>
> The story so far:
>
> I've created an extension which diverts all zend_execute calls into the
>  extension -> phpthreads_execute.
> this function is a copy of zend_execute with a few modifications
> - to copy & restore things like  EG(active_symbol_table);
> - to malloc lock and unlock the execute loop and release on each
> opcode.
>
> I've started testing the phpthreads_create($callback); - it appears to
> work ok, execept it segfaults on completion.. - trying to reduce
> refcounts somewhere.
>
> The fireup code looks something like this..
>
> void phpthreads_create(void *ptr) {
>zval myretval;
>zval *callback = (zval *) ptr;
>
>if (!call_user_function( EG(function_table), NULL, callback,
> &myretval, 0, NULL TSRMLS_CC ))  {
>zend_error(E_ERROR, "Problem Starting thread with
> callback");
>}
>
>pthread_exit(NULL);
>
>
> }
> /* {{{ proto string phpthreads_thread(string function)
>   Return a string to confirm that the module is compiled in */
> PHP_FUNCTION(phpthreads_create)
> {
>
>zval *callback;
>pthread_t thread;
>
>  if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z",
> &callback) == FAILURE) {
>  return;
>  }
>pthread_create( &thread, NULL, (void *) phpthreads_create,
> (void*) callback);
>RETURN_TRUE;
> }
>
> and the backtrace of the simple threaded test looks like this..
> 0x08128f08 in _zval_ptr_dtor (zval_ptr=0x81b5ce8) at
> /usr/src/php/php4/Zend/zend_execute_API.c:275
> 275 (*zval_ptr)->refcount--;
> (gdb) bt
> #0  0x08128f08 in _zval_ptr_dtor (zval_ptr=0x81b5ce8) at
> /usr/src/php/php4/Zend/zend_execute_API.c:275
> #1  0x424ceba2 in ?? ()
> #2  0x424c7c92 in ?? ()
> #3  0x08130588 in zend_execute_scripts (type=8, retval=0x0,
> file_count=3) at /usr/src/php/php4/Zend/zend.c:810
> #4  0x08110abd in php_execute_script (primary_file=0x40006c71) at
> /usr/src/php/php4/main/main.c:1398
> #5  0x08110138 in php_module_shutdown () at
> /usr/src/php/php4/main/main.c:1058
> #6  0x2e325f43 in ?? ()
>
> does anyone want to suggest what might be missing - is it worth putting
>  this into pecl - and does someone what to lend a hand??
>

well, not until it doesn't segfault after every request, no. :)

I'd also think you'd need a quite larger subset of Pthreads, and perhaps
focus on an OO solution (like what Perl does), but that's all surrounding
elements.

Good luck with threading the Zend Engine :P

-Sterling

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




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

[PHP-DEV] Re: GD library and PHP

[Sterling Hughes]

Dmitry,

Sorry, for the length of my reply, and now the fact that I'm just
refferring you to another source.  I'm actually not responsible for the
gd library (at least since I last checked :).  Your help would
definitely be appreciated, I've forwarded this request to
[EMAIL PROTECTED] which is the developers mailing list.  If you
would like to work on the gd extension, please feel free to apply for a 
cvs account at: http://www.php.net/cvs-php.php

Thanks,
Sterling

> Hello,
> 
> I have recently learned that GD library is being integrated into 
> PHP, and apparently you have some relation to that.
> 
> While GD library has a very good set of functions, the 
> implementation is very poor in my opinion. The code is quite 
> redundant and un-optimized in any way. This probably has to be 
> addressed to the author of GD, but since it is now going to be 
> part of PHP, may be some apparent optimization can be applied to 
> the bundled version.
> 
> My concerns raised when I tried to use ImageCopyResampled 
> function. It nearly brings my server to its knees due to high 
> memory and processor usage (when running 15-20 Apache processes 
> each processing some image via ImageCopyResampled in PHP). The 
> processing time is also very high - typically around 10 seconds 
> for 1 calls to ImageCopyResampled with 1-2 megapixel images.
> 
> Of course, those numbers relate to my server, people with faster 
> computers may get better results.
> 
> By in any case, I decided to look into implementation of 
> gdImageCopyResampled in GD library and saw lots of this that can 
> be improved. I did not look into other function, but I suspect 
> this is true for the whole GD library.
> 
> The function uses brute force approach and many values that can 
> be calculated in the outer loop or outside of any loops are 
> being calculated in the inner loop. E.g.
> 
> sy1 = ((float) y - (float) dstY) * (float) srcH / (float) dstH;
> sy2 = ((float) (y + 1) - (float) dstY) * (float) srcH / (float) dstH; 
> is being calculated for each x, while it really needs to be calculated for each y.
> 
> This part is a constant: 
> 
> (float) dstY * (float) srcH / (float) dstH
> 
> and therefore can be calculated once per call, not dstW*dstH*2 times.
> 
> Similarly,
> 
>   int pd = gdImageGetPixel (dst, x, y);
> 
> is being called inside of the inner loop (dstW*dstH times!) = but 
> is not being used anywhere later!
> 
> Applying some apparent mathematics, we can calculate the final 
> spixels value in one easy step, rather than using (potentially) 
> multiple floating point additions and multiplications in the inner loop (spixels 
> += xportion * yportion). Instead total spixels value for the current (x,y) can be 
>found as 
> 
> spixels = (y2-y1)* (x2-x1); // and, again, this can also be optimized further
> 
> I can point out several other things that can be easily improved, but you got my 
>point already.
> 
> It is possible to reduce number of calculation dramatically, without breaking 
>readability and/or 
> compatibility. 
> 
> I am wondering if anyone is considering to do this any time soon. I would be more 
>than willing 
> to discuss my suggestions with someone responsible for this library, or even modify 
>the code 
> myself (a little bit harder for me, since I have little time to make extensive 
>tests).
> 
> Regards,
> Dmitry
> 
> -- 
> Dmitry Petrov
> phone: (212) 641-3235
> pager: [EMAIL PROTECTED]
> 
> 
> -- 
> 
> *** DISCLAIMER ***
>  
> This message is intended only for the use of the individual 
> or entity to which it is addressed and may contain information
> that is privileged, confidential and exempt from disclosure 
> under applicable law.  If the reader of this message is not 
> the intended recipient or the employee or agent responsible 
> for delivering the message to the intended recipient, you are 
> hereby notified that any dissemination, distribution or copying 
> of this communication is strictly prohibited.  If you have received
> this message in error, please notify the sender by reply
> transmission and delete the message.
> --
> 
> 

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

Re: [PHP-DEV] New FTP extension functionality

[Sterling Hughes]

> Hi,
> 
> yesterday I did several commits to the FTP extension. Due to the fact that
> I do not know how I can document the stuff myself and right now am lacking
> the time here is a brief instruction:
> 

The work looks quite cool, however this is really not asynchronous i/o,
but rather non-blocking i/o.

-Sterling

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

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

Re: [PHP-DEV] Patch for xslt -> Showing Sablotron Version number in phpinfo()

[Sterling Hughes]

> Hi
> 
> The Subject says it all. It's quite useful to have the Sablotron version
> number in phpinfo, therefore I added this. It's available at
> http://trash.chregu.tv/sablot-version.diff
> 
> Would be great, if someone with enough karma could add it.
> Unfortunately the version number seems  only to be available since sablot
> 0.95, but better than nothing :)
>

patch added to cvs.

-Sterling

> chregu
> 
> 
> -- 
> christian stocker | bitflux GmbH | schöneggstrasse 5 | ch-8004 zurich
> phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
> http://www.bitflux.ch  |  [EMAIL PROTECTED]  | gnupg-keyid 0x5CE1DECB
> 
> 
> 
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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