[PHP-DEV] segfault with ze2/php5-cvs
?php
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
Re: [PHP-DEV] segfault with ze2/php5-cvs
On Fri, 2003-03-21 at 15:12, Joey Smith wrote:
Very nice.
What about:
?php
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:
?php
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] ze2 segfault #2
When running the following example through pres2 (apache 1.3.27), I get
a segfault.. Sample pres2 file.
slide
titleInterfaces Suck/title
blurbThey really do/blurb
example filename=interface2.php result=1 /
/slide
interface2.php::
?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
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ze2 segfault #2
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.
slide
titleInterfaces Suck/title
blurbThey really do/blurb
example filename=interface2.php result=1 /
/slide
interface2.php::
?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] Re: [PHP-CVS] curl multi
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
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 http://www.php.net/ 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 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
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 http://www.php.net/ 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 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
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] Tie'ing variables
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
[PHP-DEV] Tie'ing variables
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
Re: [PHP-DEV] Tie'ing variables
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tie'ing variables
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] Mono PHP
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] Mono PHP
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.
?php
$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
Re: [PHP-DEV] OO in PHP5 (was zend_API.c on php-dev)
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Mono PHP
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.
?php
$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.
--
First they ignore you, then they laugh at you,
then they fight you, then you win.
- Gandhi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Practical question
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP and XML mailing list
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ADT alpha 1
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Feature Request: Auto Include a Function
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: ?php $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 already. One possibility for implementation is just prior to the undeclared function error message, try to auto include the function prior to generating the error message. Thanks, Brian Allen [EMAIL PROTECTED] -- PHP Development Mailing
[PHP-DEV] php5 object model
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
--
?php
$stack = adt_stack_new();
for ($i = 0; $i 100; ++$i) {
adt_stack_push($stack, $i);
}
var_dump(adt_stack_pop($stack));
adt_stack_free($stack);
?
Object Oriented
--
?php
$stack = new adt_stack();
for ($i = 0; $i 100; ++$i) {
$stack-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
zval_update_constant, 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
zval_update_constant, 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Fwd: 4.3.0 w/ Sablotron version check problem]
-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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...
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] ZEND_NUM_ARGS()
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_NUM_ARGS()
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memleak in string.c?
/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 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] CGI and CLI
This note from Derick pretty much reflects the idea... it makes sense: quote 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). /quote 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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] -+ [01]
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-cgi vs php-cli naming issue
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-cgi vs php-cli naming issue
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
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
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 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] Zend fast cache
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] [PATCH] Changes to ext_skel for C++
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Zend fast cache
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend fast cache
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
Re: [PHP-DEV] call_stack
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
err. it didn't need a reimplementation, i fixed it, it works fine in cvs. Then, ?php $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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
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 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] Redirect on Error (not localisation)
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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.
?php
$answer = ($fine == $best);
echo Result: $answer;
?
Result: false
?php
if (!isset($question)) {
print Who cares about the answer\n;
}
?
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] curl_exec hangs
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
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] turning strlen() into an opcode
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
Re: [PHP-DEV] Do I need the closing ? tag
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
[PHP-DEV] Re: #19848 [Ctl-Csd]: Wrong $_REQUEST values ($_FILES appearanceis wacky)
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: FORM METHOD=POST ACTION= INPUT TYPE=text name=foo[a] VALUE=?=$foo['a']? INPUT TYPE=submit /FORM 2 dimensional array - this test form strips 8 characters from the posted variable: FORM METHOD=POST ACTION= INPUT TYPE=text name=foo[a][b] VALUE=?=$foo['a']['b']? INPUT TYPE=submit /FORM 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. form method=post action=test.php input type=checkbox name=server[] value=ASP input type=checkbox name=server[] value=C input type=checkbox name=server[] value=COLDFUSION input type=checkbox name=server[] value=JAVA input type=checkbox name=server[] value=PERL input type=checkbox name=server[] value=PHP /form 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=19848edit=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
[PHP-DEV] Work is beginning on cURL and PHP again
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Work is beginning on cURL and PHP again
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
Re: [PHP-DEV] Work is beginning on cURL and PHP again
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
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
[PHP-DEV] Re: Curl Multi Interface Patch
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Curl Multi Interface Patch
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 brch1=.strlen($c1);
echo brch2=.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 *ch;
+php_multi_curl *multi_handle;
+CURLcode error;
+
+if (ZEND_NUM_ARGS() != 2 ||
+zend_get_parameters_ex(2, zidm, zidc) == FAILURE
+) {
+WRONG_PARAM_COUNT
[PHP-DEV] Re: Curl Multi Interface Patch
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] $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
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: INPUT TYPE=file NAME=toto[c] 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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
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: INPUT TYPE=file NAME=toto[c] 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
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: ext/xslt
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 existing functions), but it lacks the document creation functions. It only allows for parsing. We could also move ext/xml to ext/xml-parser but I don't think it's a good idea. IMO it will not compete with DomXML, simply because it's procedural
[PHP-DEV] Re: RFC: ext/xslt
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Save the Orphans - No this isn't coming from a friend in Nigeria
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mem leaks
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ADT CVS Commits
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
-
This mail sent through IMP: http://horde.org/imp/
--
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
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE:
-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 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
Re: [PHP-DEV] mbstring
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 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] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-distphp.ini-recommended /main main.c output.c php_globals.h php_output.h
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Ways to Encourage PHPv5 usage
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Major Problem
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 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] Re: adding tcsetattr to dio extenstion
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
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ZEND_* instead of PHP_*
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 )\nfcomments[i] */\nPHP_FUNCTION(
funcs[i] )\n{
+ proto = proto closeopts )\nfcomments[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_len, len;
--
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
Re: [PHP-DEV] phpthreads - hints anyone...
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for xslt - Showing Sablotron Version number in phpinfo()
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 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] New FTP extension functionality
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: GD library and PHP
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: fleaslob
To help improve the documentation, especially the Italian and German translations. hey, just to vouch for him, he's a co-worker of mine in italy, and can speak italian and german fluently (well, ok, at least it seems german and italian people understand him :). He's also a good (php) programmer, so no worries there :) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_exists() stopped working
Sterling Hughes wrote: hrmm, ok.. I'll add a patch to filestat.c by tommorow which fixes these problems. Just don't forget it :) just a note that I haven't forgotten it, patch is pending until I get non- pos-hotel-5-euro-for-30-minutes-on-shit-computer internet access. -Sterling -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List 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] file_exists() stopped working
file_exists() seems to return always FALSE on Win32 with current HEAD. hrmm, ok.. I'll add a patch to filestat.c by tommorow which fixes these problems. I really wish we were using apr or such. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
