Re: [PHP-DEV] Moderate PHP-DEV
Sterling Hughes wrote: In what country can you walk onto the floor of the congress (parliament) without sponsorship? OTOH in which country do you *trust* your parliament? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Announcement: Next generation ext_skel
l0t3k wrote:
Hartmut,
will this also generate zend_parse_parameters calls based on prototype ?
Sure, see the two samples below. It even adds return statements for the
return type specified in the proto where possible.
But unlike the current ext_skel it also supports code generation for
php.ini values, module globals, constants and resourcetypes ... :)
---
function role='public' name='dummy_int'
summarydummy integer conversion/summary
protoint dummy_int(int bar)/proto
/function
/* {{{ func int dummy_int(int bar)
dummy integer conversion */
PHP_FUNCTION(dummy_int)
{
int argc = ZEND_NUM_ARGS();
long bar = 0;
if (zend_parse_parameters(argc TSRMLS_CC, l, bar) == FAILURE) return;
php_error(E_WARNING, dummy_int: not yet implemented);
RETURN_LONG(0);
}
/* }}} */
---
function role='public' name='dummy_resource'
summarydummy resource test/summary
protoresource dummy_resource(resource bar)/proto
/function
/* {{{ proto resource dummy_resource(resource bar)
dummy resource test */
PHP_FUNCTION(dummy_resource)
{
zval * bar = NULL;
int * bar_id = -1;
int argc = ZEND_NUM_ARGS();
if (zend_parse_parameters(argc TSRMLS_CC, r, bar, bar_id) == FAILURE) return;
if (bar) {
ZEND_FETCH_RESOURCE(???, ???, bar, bar_id, ???, ???_rsrc_id);
}
php_error(E_WARNING, dummy_resource: not yet implemented);
}
/* }}} */
--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77
Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Announcement: Next generation ext_skel
Jani Taskinen wrote: Krhm...you should make it to produce code that meets our coding standards.. :) Use tabs, ... sure, but especially tabs have a very low priority on my list, as having them as '\t' in the generating PHP code hurt readability a lot (and emacs is not clever enough to enforce c-mode indentation settings on code embedded into PHP strings) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new construct
Andrew Heebner wrote: This is done by design, not by 'bugginess'. For backwards compatibility, if the Zend Engine 2.0 cannot find a __construct() function for a given class, it will search for the old-style constructor function, by the name of the class. in the exmaple it uses the 'old style' constructor *although* __construct() could have been found ...? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
Sascha Schumann wrote: But a simple wrapper for a two-line fopen/fputs? Get real. you forgot the fclose() ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Jumadi
[EMAIL PROTECTED] wrote: Only one question: why not change the name of this mailing list ??? Only a idea. it is already advertised as Internals list A medium volume list for those who want to help out with the development of PHP on http://www.php.net/mailing-lists.php, so maybe changing its name to something like php-internal@ php-dev-internal@ or php-internal-dev@ might really be something to be considered ...? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Announcement: Next generation ext_skel
i've just added the first working results of a replacement for the good old ext_skel script in php/scripts/ext_skel_ng ext_skel_ng is meant to replace the current ext_skel completely, and IMHO it is already at least as capable as the old one. ext_skel_ng is a 'pure' php solution, it only depends on php itself and the xml extension which is enabled by default instead of a simple proto file and some command line options it is now completely driven by an XML file similar to (and inspired by) the PEAR package.xml format code generation is already a little more clever than the previous template apporach, and preliminary support for M$ developer studio .dsp project files has just been added :) see the attached README file below for further info ... - php/scripts/ext_skel_ng/README sorry, no real documentation yet ... just a short look at what is going on ext_skel_ng.php gets an extension description from an extension.xml file and generates working code and documentation stubs from that call php ext_skel_ng.php to see it at work, it will create a dummy extension including - module globals and ini paramter setup - function registration and stubbs - documentation framework - config.m4 (only minimal for now) - ... almost every aspect of an extension may now be configured using one xml description file instead of the old mixture of command line parameters and a proto file it is even possible to embed function code into the xml description right away, so it should be possible to create complete working extensions from just the xml description without further editing in a not to distant future for now almost all the 'helpfull comments' have been removed from the generated code. some of them (like 'uncomment this if you have ini params) just don't make sense anymore, others will come back (configurable) at a later state ... have fun! -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new Date extenstion
Pierre-Alain Joye wrote: ext/calendar has support for all this ... it even knows about the french revolution calendar ;) rofl :) Well, I'm talking about a good and usefull date/time extension. I do not say calendar is not good, but it does not cover what we need for a good, crossplatform date/time modules :) ext/calendar is about date only, not about time but i can't see where it is not cross-platform ... and if you want to come up with something usefull even for historians you have to deal with different transition dates from julian to greorian in addition to time zones and different daylight saving time switch dates ext/calendar is not perfect, but all the algorithms are in there ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new Date extenstion
Pierre-Alain Joye wrote: Actually no, date corrections will be part of the date functions as soon as the locale part is done. The changes of calendar was not the same in each country, not in the same time, and even not in the same country (I like scottland, switzerland or others proud people ;-), there are ambiguous common days offset, some use it, some not. That is one of the things we should discuss, and document our choice as well. What do you think ? ext/calendar has support for all this ... it even knows about the french revolution calendar ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: function.main
Gabor Hojtsy wrote: That is if I understand correctly a link in an error message. So either PHP needs to hide that link in error messages, or the function.main shortcut shuold point to somewhere on the homepage, explaining what is function.main speaking of the link feature: can't we deactivate that for error_log output? error messages in the logfiles are almost unreadable right now (at least it takes a long time to identify the actual message, esp. on 'file not found' types of messages)? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: function.main
Gabor Hojtsy wrote: If you turn of html_errors, that should turn off that link too IMHO, not tested though... well, what if i want html errors in the html output but not in the error_log (where they dont make sense) ? ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Database Abstraction
Kasper Skårhøj wrote: but internally parses the queries and re-makes the query into something Oracle or MSSql or some third DB would understand. This would be totally transparent and give instant DBA to millions of PHP-scripts. A MySQL emulator. ODBC does something similar AFAIK, just with ANSI SQL as standard dialect instead of MySQL ... but still i'd like to see how you are going to get features like auto-increment or fulltext search 're-made' ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: version names
Kai Schröder wrote: That's true. Now we have round about 30 commits each day. 12 more will make less than 5.000 blocks (5MB for 1k-blocks) more disk usage per year. Where do you see the real problem if the commits are not mailed to php-cvs list? that is 12 commits per day to a single file after a year this file would have a cvs release id of something like 1.4500 take a look at http://cvs.php.net/cvs.php/php4/NEWS to see why this might be a not-so-good idea ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP4 + PHP5
Zeev Suraski wrote: Wouldn't --enable-versioning work just fine? It didn't even work fine with php3/php4 last time I tried it. I was under the impression it works well... on some systems (Solaris ...) it will disable extension loading as there it does not only hide symbols towards the loader of the php module itself, but also from everything it loads itself :( the behaviour depends on the runtime linker/loader used, i know for sure that it works for linux and fails for solaris, and afair *bsd won't work either -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP-4.3.0RC3 Windows - getopt function
Kjartan Mannes wrote: The NEWS file mentions a new function getopt(), but I can not get this to work under windows. Fatal error: Call to undefined function: getopt() My guess is that getopt() isn't a standard system function, but PHP mimics the function as it handles command line arguments. Is this intentional or just an oversight? for now it is Unix-only ( Actualy it is protected by #if HAVE_GETOPT and configure deals with it checking for getopt() in libc. On Windows there is nothing like configure so this has to be solved in a different way. ) any Win32 volunteers? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOCUMENT_ROOT with Zend API
Krzysztof Socki wrote: Hello! I'm writing a new function to PHP using the Zend API. I need to know the DOCUMENT_ROOT value of the running script. I've read through the lxr.php.net and I still have no idea how to do that. Is it possible with the Zend API, at all? Does anybody know the way? it is in $_SERVER hash if the SAPI provided it, so that is the place to look for ... is this still about your include-hiding? ever considered auto-prepend files for this? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOCUMENT_ROOT with Zend API
Krzysztof Socki wrote: Hello! I'm writing a new function to PHP using the Zend API. I need to know the DOCUMENT_ROOT value of the running script. I've read through the lxr.php.net and I still have no idea how to do that. Is it possible with the Zend API, at all? Does anybody know the way? Krzysiek Socki [EMAIL PROTECTED] and *PLEASE* make some space in your inbox before sending further questions getting E-mail Account: imprev is over the limit of 31457280 bytes. auto-replies all the time is starting to get very annoying -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Stuffed Inbox on imprev account (phplists@imprev.com ?)
Hartmut Holzgraefe wrote: and *PLEASE* make some space in your inbox before sending further questions getting E-mail Account: imprev is over the limit of 31457280 bytes. auto-replies all the time is starting to get very annoying sorry, should learn to read mail headers more carefully so whoever is related to this account - *PLEASE* turn it off -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- 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
Shane Caraveo wrote: It would have been simple enough to combine cli into the cgi binary and be done with it, and I suggested as much that it should be done a very long time ago. I don't recall any major reasons why it wasn't done, other than that cli has been experimental. Way back CGI and CLI *did* share one binary (the CGI binary) and the code was cluttered with code behaviour depending on the environment the binary was called in. The code with all these situation-dependant if() blocks was a true mess getting even worse with every new CGI- or CLI-only feature added. Even worse: some features and extensions don't make sense in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other features belong into a CGI binary only. The introduction of the seperate CLI binary or SAPI happened for two reasons: - removal of situation-dependant code in the CGI thus cleaning up the code base(as stated above) - the ability to build the CLI alongside with *every* SAPI So we can argue about binary naming, but definetly *not* about about the CGI/CLI split. No matter how similar the two binaries might look, they *aren't* -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 'include' function
Krzysztof Socki wrote:
Hello!
Can anyone tell me if it's possible to extent PHP with a function that
includes other PHP file? I know that 'include' is not a function, is it
possible to work it around? I need a function that includes a file
respective to the location of the running script. Maybe I could extend the
parser to use an alias of 'include' with a constant file path? I'd be
grateful for your help. Thanks in advance.
function include_me($path) {
include $path;
}
should do the trick?
--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.: +49-711-99091-77
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_*
[EMAIL PROTECTED] wrote: Okay, some of them are in ctype. But it should be easier to have them in standard so basic user should use them. ctype is enabled by default in 4.3 ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_*
[EMAIL PROTECTED] wrote: What about making FALIASES so it can be found in is_*? Really easier for newbies. We want to get rid of function aliases whereever possible, not generate new ones. We talked about the naming for the ctype functions back then when i wrote them and decided not to use is_* as this would clutter the is_* namespace even more. (actualy agreement was reached to call them ctype_is_* but somehow i didn't get that, but that is a different story) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RAW POST DATA
Andrei Zmievski wrote: On Tue, 12 Nov 2002, Hartmut Holzgraefe wrote: the current problem with HTTP_RAW_POST_DATA is just that i never really figured out when it should be populated depending on HTTP method, Content type and always_populate_raw_post_data, this is going to be fixed today Okay. HTTP_RAW_POST_DATA now behaves exactly like with 4.2: always...off...on php://input POST without content typeyes yes yes POST with default FORM type no yes yes POST with multipart FORM typeno no* no** POST with unknown content type yes yes yes PUT and other methodsno noyes * This is different as in 4.0/4.1 due to the new streaming rfc1867 handler. ** would be possible to implement without wasting memory, but not in time for 4.3 besides the HTTP_RAW_POST_DATA issue what i did was a cleanup of the HTTP content handler code in SAPI.c that fixes problems with PHP not comsuming content data although at least the apache 1.x API relies on it (for keepalive connections) That needs to be tested pretty well, I imagine? works for me ;) (and CGI testing - needed for POST tests - is still broken :o ) i didn't touch the actual post data parsing, just cleaned up the interface between SAPIs and PHP post handlers the cleanup for keepalive is just a loop in the request shutdown part that calls the SAPIs read_post handler until no further data is returned by that regarding run-tests.php and CGI i have a patch that makes php-cgi accept command line parameters (as needed for ini settings and stuff in run-tests.php) even if it detects a CGI environment setup (which makes it ignore argc/argv switches like -q, -f and -d right now) if the USER_AGENT is set to run-tests.php i have also added an --ENV-- section for .phpt files so that it is possible to set things like CONTENT_TYPE, REQUEST_METHOD and others, this i needed for WebDAV tests ... but this is another story ... php://input works for the apache sapi, but not with CGI i had no time yet to realy dig into it but i'm pretty sure it is a problem within the CGI sapi code and not in the content handler ... i definetly want this feature in 4.3 as with plain 4.2.x it is impossible to handle PUT and WebDAV requests and even with the allow_webdav_methods patch and HTTP_RAW_POST_DATA extended to PUT and WebDAV specific methods you get back the same memory consumption problems as with file uploads before 4.2.0 This php://input thing is what concerns me. How much time do you need to finish and test it? We don't want to delay RC1 too much. it is finished (it is just a simple stream that interfaces to the SAPI read_post handler if content had not been parsed by some PHP post handler. if a post handler had been used and the data it read is still available in SG(request_info) it delivers this from memory instead, and if the post data is no longer available as with the rfc1867 multipart/form-data handler it returns EOF right away i already use this for webdav instead of HTTP_RAW_POST_DATA without problems and have figured out what made CGI fail yesterday, so now it works for me with both apache 1.x and cgi sapi. as all it relies on is the current SAPIs read_post handler it should be working with all other SAPIs as well as long as read_post is defined and working in that SAPI, and with SAPIs that don't provie read_post (like CLI) it is just a no-op -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RAW POST DATA
Hartmut Holzgraefe wrote: Jan Schneider wrote: To resume: best practice is currently to use $HTTP_RAW_POST_DATA if available and php://input else. And crossing fingers that either of them works, of course. ;-) hmyes, but it *should* be to use php://input and forget about $HTTP_RAW_POST_DATA alltogether hopefully ... from now on i declare it best practice to use php://input for 4.3 while $HTTP_RAW_POST_DATA is still available for BC reasons ... :) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RAW POST DATA
Markus Fischer wrote: If I just want to see the RAW data it's still easier to do var_dump($HTTP_RAW_POST_DATA); than anything else to me. now you can do readfile(php://input); this has the following advantages: - less typing, saves you 6 keystrokes ;) - does not only work for POST, but also for PUT, ... - does not eat memory and the following disadvantages: - works only once, there is no rewind for this stream - is not BC for pre-4.3 versions -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RAW POST DATA
for the majority of file uploads. Another alternative for multipart/form-data would be to just store the non-file parts in memory and read back (and MIME-encode) the uploaded files now stored in temporary disk files back on demand, so presenting the user a reconstruction of the original input content. This approach would preserve resources by avoiding redundant storage of data but would also require every content handler that does not just maintain a in-memory copy of input data to provide an interface for data reconstruction. None of these approaches has yet been taken, instead raw data is just simply not provided for multipart/form-data requests since 4.2, and i don't see a way to fix this for 4.3 within a reasonable time frame. Still i think my introduction of the php://input stream is a great inporvement over the 'raw' variable, especially with file PUT and WebDAV requests in mind. What definetly needs to be fixed is my complete missinterpretation of $HTTP_RAW_POST_DATA itself and the always_populate_raw_post_data setting, this will be done later today (but multipart/form-data POST requests will still be ignored no matter what always_populate... is set to due to memory preservation reasons) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RAW POST DATA
Jan Schneider wrote: Do you mean, this is your plan or this already works? php://input already works with apache 1.x it should be SAPI independant, but for some strange reason it doesn't work for CGI right now, and i haven't tested any other SAPIs yet but with the apache 1 module i already use it for WebDAV PUT and it works fine for me :) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RAW POST DATA
Jan Schneider wrote: To resume: best practice is currently to use $HTTP_RAW_POST_DATA if available and php://input else. And crossing fingers that either of them works, of course. ;-) hmyes, but it *should* be to use php://input and forget about $HTTP_RAW_POST_DATA alltogether hopefully ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RAW POST DATA
Andrei Zmievski wrote: How much is this going to delay 4.3.0? I'm just a bit wary of changing such an essential part of PHP interaction (with server and users) before a big release.. the current problem with HTTP_RAW_POST_DATA is just that i never really figured out when it should be populated depending on HTTP method, Content type and always_populate_raw_post_data, this is going to be fixed today besides the HTTP_RAW_POST_DATA issue what i did was a cleanup of the HTTP content handler code in SAPI.c that fixes problems with PHP not comsuming content data although at least the apache 1.x API relies on it (for keepalive connections) php://input works for the apache sapi, but not with CGI i had no time yet to realy dig into it but i'm pretty sure it is a problem within the CGI sapi code and not in the content handler ... i definetly want this feature in 4.3 as with plain 4.2.x it is impossible to handle PUT and WebDAV requests and even with the allow_webdav_methods patch and HTTP_RAW_POST_DATA extended to PUT and WebDAV specific methods you get back the same memory consumption problems as with file uploads before 4.2.0 btw: did someone work on the run-tests.php/CGI issues? does it work again? because with CLI it is not possible to test POST handling ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PUT method support
looks like this was a PHP3 only feature? http://www.php.net/manual/sv/printwn/features.file-upload.put-method.php -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $HTTP_RAW_POST_DATA
Philip Olson wrote: When setting this on I assume it will always populate no matter what enctype is used. This isn't the case. In the little tests according to Brad, adding enctype=multipart/form-data to a post form will cause $HTTP_RAW_POST_DATA to not exist. This is even with aways_populate_raw_post_data = on. unless i did something stupid while testing this is also the case at least for 4.2.x (due to the way multipart forms are handled now to preserve memory on file uploads) ... maybe it is time to set up a table of when what is populated related to HTTP method, Content-Type and always_... setting? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding mail() Parameter to Set Return Path
Michael Sisolak wrote: The only downside I see to this is that the value would only work for the internal Win32 sendmail code and not the standard Unix calls to sendmail. A windows-only solution for a standard PHP function? Who uses PHP on Win32 for serious stuff anyway? ;) now serious: this is just another argument for dropping the sendmail kludge and come up with a working SMTP implementation for both platforms ... (we can still keep sendmail delegation as a less featured fallback if SMTP is not configured) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding mail() Parameter to Set Return Path
Melvyn Sopacua wrote: At 11:29 31-10-2002, Hartmut Holzgraefe wrote: -- Why should I need to open a network socket with all problems that may arrise with it, when I can call a binary? why bother with additional subprocesses, incompatible command line interfaces, a command line interface that wasn't even really meant to be used for non-human interaction? the only advantage of using the sendmail binary on unix is that you usualy can rely on it being already configured besides that *all* the problems with mail() (one process per mail unless you bcc: identical copies, From: setting, no influence on SMTP envelope, ...) simply do not exist with SMTP based solutions (unless they are so badly coded as the win32 mail() implementation has been in the past ...) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] running tests with CGI binary
fact #1: some tests *require* cgi sapi (eg. POST stuff)
fact #2: current test suid *does not work* with php-cgi
conclusion: a lot of stuff doesn't get any automatic testing
solution: (see attached patch)
- run-tests.php sets USER_AGENT=run-tests.php
- run-tests.php prepends testcode with chdir()
- php-cgi falls back to argc/argv parsing even
if in cgi mode when USER_AGENT=run-tests.php
with the patch applied the following works again:
export TEST_PHP_EXECUTABLE=sapi/cgi/php-cgi
sapi/cli/php run-tests.php
comments? ;)
-8-
Index: run-tests.php
===
RCS file: /repository/php4/run-tests.php,v
retrieving revision 1.83
diff -u -2 -r1.83 run-tests.php
--- run-tests.php 23 Oct 2002 12:54:57 - 1.83
+++ run-tests.php 24 Oct 2002 09:26:06 -
@@ -83,4 +83,6 @@
}
+$php = realpath($php);
+
// Check whether a detailed log is wanted.
if (getenv('TEST_PHP_DETAILED')) {
@@ -425,4 +427,5 @@
// Reset environment from any previous test.
+ putenv(USER_AGENT=run-tests.php);
putenv(REDIRECT_STATUS=);
putenv(QUERY_STRING=);
@@ -437,7 +440,8 @@
if (trim($section_text['SKIPIF'])) {
save_text($tmp_skipif, $section_text['SKIPIF']);
- $output = `$php $tmp_skipif`;
+ putenv(PATH_TRANSLATED=$tmp_skipif);
+ $output = `$php -q $tmp_skipif`;
@unlink($tmp_skipif);
- if (ereg(^skip, trim($output))){
+ if (ereg(^skip, $output)){
echo SKIP $tested;
$reason = (ereg(^skip[[:space:]]*(.+)\$, trim(
$output))) ? ereg_replace(^skip[[:space:]]*(.+)\$, \\1, trim($output)) : FAL
SE;
@@ -478,5 +482,5 @@
// We've satisfied the preconditions - run the test!
- save_text($tmp_file,$section_text['FILE']);
+ save_text($tmp_file,?php chdir('.getcwd().'); ? . $section_text['F
ILE']);
if (array_key_exists('GET', $section_text)) {
$query_string = trim($section_text['GET']);
@@ -502,6 +506,5 @@
putenv(CONTENT_LENGTH=$content_length);
- $cmd = $php$ini_settings -f $tmp_file 21 $tmp_post;
-
+ $cmd = $php -q $ini_settings -f $tmp_file 21 . realpath($t
mp_post);
} else {
@@ -510,5 +513,5 @@
putenv(CONTENT_LENGTH=);
- $cmd = $php$ini_settings -f $tmp_file$args 21;
+ $cmd = $php -q $ini_settings -f $tmp_file$args 21;
}
@@ -524,6 +527,6 @@
;
- $out = `$cmd`;
-
+ $out = `$cmd`;
+
@unlink($tmp_post);
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v
retrieving revision 1.183
diff -u -2 -r1.183 cgi_main.c
--- sapi/cgi/cgi_main.c 13 Oct 2002 09:40:44 - 1.183
+++ sapi/cgi/cgi_main.c 24 Oct 2002 09:26:06 -
@@ -523,5 +523,5 @@
{
int exit_status = SUCCESS;
- int cgi = 0, c, i, len;
+ int cgi = 0, c, i, len, testmode = 0;
zend_file_handle file_handle;
int retval = FAILURE;
@@ -574,4 +574,8 @@
#endif
+#ifndef PHP_FASTCGI
+ s = getenv(USER_AGENT);
+ if(s !strcmp(s, run-tests.php)) testmode = 1;
+#endif
#ifdef ZTS
@@ -876,9 +880,9 @@
zend_llist_init(global_vars, sizeof(char *), NULL, 0);
- if (!cgi
+ if ( testmode || (!cgi
#ifdef PHP_FASTCGI
!fastcgi
#endif
- ) { /* never execute
the arguments if you are a CGI */
+ )) { /* never execute the arguments if you are a CGI unl
ess in testmode*/
if (SG(request_info).argv0) {
free(SG(request_info).argv0);
--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.: +49-711-99091-77
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Yasuo Ohgaki wrote: There is cons also. Users may be looking the file with tail... this user will most likely *expect* line-based output -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Script Abortion
Maxim Maletsky wrote: i think it already does. i think that was not the question, but *how*? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?
Edin Kadribasic wrote: Doing flush after each output operation does carry a performance penalty. The following example illustrates it: php -d implicit_flush=0 -r 'for ($i=0; $i100; $i++) echo $i;' file This one executes about twice as fast on my machine compared to php with implicit_flush turned on. The example is of course written to emphasise the issue. ? default implicit_flush to isatty(stdout) should help here? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: output buffering
Zeev Suraski wrote: Aha, ok, that actually makes quite a bit of sense. If there's a bit of output that remains inside the buffers, and the session module gets deactivated before this output is flushed, we're in trouble... I'll take a look at it. i think i've been bitten by this using apxs ... :( at least i've been suffering xml output missing some bytes at the end in a project where a trans-sid session was started for the xml generating script by an included file (although there was no actual need for a session, so 'fixing' the problem was easy in that case) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thread Reading
[EMAIL PROTECTED] wrote: I *do* think that line numbers being linked like lxr.php.net is a good idea and is a really easy thing to code. +1's? However, turning it on based on linking to a numbered link isn't a great idea as links with # are much more common than people using ?HIGHLIGHT_FORMAT. Nobody uses GET parameters or #anchors with .phps nowadays, or have i missed something? for me a h http://www.example.com/somepath/file.phps#1 is just easier to remember than http://www.example.com/somepath/file.phps?HIGHLIGHT_FORMAT=... and i can't see any conflicts with existing stuff in that (but then i'm lazy and my memory is getting worse while i get older ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thread Reading
Devon O'Dell wrote: Simple fix :) [...] http://www.dapond.net/code/backtrace.phps?HIGHLIGHT_FORMAT=lineno This last url doesn't output anything. Maybe because the HTML is broken? missing /table hm, what's the use of having a table here? why not just one big code environment as in the un-numbered version preceded by line numbers in a format like sprintf(%4d: %s\n, line_no, line); ? or even better: with html anchors for the lines sprintf(a name='%d'/a%4d: %s\n, line_no, line_no, line); similar to what we have on lxr.php.net? so that you can give out links to certain lines in the code: http://www.dapond.net/code/backtrace.phps?HIGHLIGHT_FORMAT=lineno#12 thinking even further: you could drop HIGHLIGHT_FORMAT altogether and activate line numbering as soon as a numeric anchor is spotted terminating the url -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thread Reading
Dan Hardiker wrote: hm, what's the use of having a table here? Because what if there is someone with a 10,000 line script? or just a 6 line script? Then the indenting will look out of place or crooked. If we are outputing in HTML, why not *use* HTML ;) Tables allows the left hand column to be flexable. Is there a problem with the table directive being used? - content size blown up - rendering overhead - some clients won't start to render tables until the outmost table is completely received by the client just to name a few ... indenting for four columns isn't that much visualy disturbing, and whoever puts 10k+ LOC into a single file has a problem anyway, so that little indentation glitch betw. line and 1 shouldn't hurt that much ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] highlight_file modification
Devon O'Dell wrote: ... there isn't another way to set it for a phps (unless you create an ini setting). what about application/x-httpd-php-source-with-line-numbers ? ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: trans-sid warning?
Dan Hardiker wrote: How you can tell a cookie to be stored in RAM rather than on the HDD, Im not sure ... but that might mean I need to brush up. do not set a lifetime and it won't be stored on disk and live in browser ram until browser is terminated has been so ever since netscape came up with cookies Now this is where the code dev needs an IQ above 3. *Use IP and Browser String authentication* eg: Load up the session ID given, check the ip and browser string (possibly even referrer) and if they dont match, squeel. IPs might change due tu proxy farms or DHCP leases expiring and getting renewed with a different IP -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Help pls!! mail() function header problems
Thomas omega Henning wrote: And as you see From: [EMAIL PROTECTED] is in the header section of the mail() function. What can I do to fix this problem? #1 read the docs #2 ask the php-general@ list, not the php-dev@ list php-dev is about development of future version of php, not about doing developement with php, our native language is more like C around here ;) from the mail() manual page: ( http://php.net/mail ) [...] The additional_parameters parameter can be used to pass additional parameters to the program configured to use when sending mail using the sendmail_path configuration setting. For example, this can be used to set the envelope sender address when using sendmail. You may need to add the user that your web server runs as to your sendmail configuration to prevent a 'X-Warning' header from being added to the message when you set the envelope sender using this method. Example 3. Sending mail with extra headers and setting an additional command line parameter. mail([EMAIL PROTECTED], the subject, $message, From: webmaster@$SERVER_NAME, -fwebmaster@$SERVER_NAME); Note: This fifth parameter was added in PHP 4.0.5. [...] -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $GLOBALS
[EMAIL PROTECTED] wrote: On Mon, 8 Jul 2002, Tit Black Petric wrote: is there an alias to $GLOBALS .. seems kinda long to type.. if not, can i suggest $_ or is it taken anywhere? [...] 2. $GLOBALS is fine, and IMO we should not implement $_ because this is against the spirit of PHP: Keep it easy to read and to write. We could talk about $_GLOBAL for consistency reasons but it definetly shouldn't get shorter IMHO. Relying on global variables is bad and should at least be punished by typing ... ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
Mike Hall wrote: Chris Shiflett wrote: I have a few sites where I deliberately violate the HTTP spec in this way to get around a bug in IE (I know, shame on me). I've been using relative URLs in a Location header for years with no crashes that I know of. There must be something unique in your configuration. Have you mentioned this to the Apache guys? I've seen this before too, but only on Windows. I've never noticed the problem on Linux, Solaris, or BSD. I had it on FreeBSD. It was particularly bad under SSL, but happened without too. may i quote this as warnings in the manual? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Yasuo Ohgaki wrote: Note in the manual page says setlocale() is not required, so I was supposing it's not needed. Anyway, it seems it's been modified recently and I haven't use gettext for long time. Need some research. It uses process-global settings to determine the language to use, so it can't be safe to use it in a threaded environment unless all threads use the same language, wich is not necessarily the case with PHP in ZTS mode. -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 4.2.2
Ilia A. wrote: Would it be possible to include the fixes made by Andy to the zend_constants.c, which resolves at least 2 major bugs with constants? Ilia doesn't the same problem apply to function and method names, too? PS: IMHO using a locale-independent tolower() alternative in the engine would be a better solution than what we have now ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Yasuo Ohgaki wrote: I think gettext module is also a good one to be enabled by default or recommend users strongly. well, as everything depending on setlocale() or putenv(LANG=...) is *not* threadsafe this might be a not-so-good idea right now ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Yasuo Ohgaki wrote: It relies on an external library, so that won't be a good thing. gettext is not available for every platform, and we are not going to bundle it. I agree. Bundling everything is not good. it's even more tricky in case of gettext, as its functions are available as a seperate library, but are also part of GNU glibc, which is the default system C library on Linux OTOH making setlocale() and gettext() work fine with ZTS without overwriting language settings for other threads might require some patching of the library functions themselve, so that might be an argument *for* bundling in this case ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Andi Gutmans wrote: Hi, I'll try and get the patch into PHP soon (I was busy with other things) I want to rewrite it a bit to make it nicer. does the case-sensitive, then case-insensitive logic really make that much sense? wouldn't it be easier *and* more consistent to make zend_str_tolower() not use libc tolower() but some locale-insensitive code instead? or am i missing something? btw, the use of strtod() within the engine is a similar problem the lexer always looks for '.' as decimal_point (which is right) but then uses strtod() to convert the found string into a double without taking in account that the decimal_point in the current locale may be a different character so that parsing stops at the '.', cutting off all decimals so strtod() should be replaced by something not locale-aware (and no, atof() is not what we are looking for) or replace the '.' with whatever decimal_point is set to in the current locale first solution would perform better, but from looking at the OpenBSD implementation of strtod() i think the second has far less potential for problems while not performing to bad if decimal_point is cached somehow ... PS: IMHO we have to rethink the complete set_locale() stuff in PHP as there is absolutely no way to make it work in threaded SAPIs :( -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 H.A.R.T.M.U.T.: Hydraulic Artificial Replicant Trained for Mathematics and Ultimate Troubleshooting -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia A. wrote: By using a functiont that does not support lowercasing, would also cause problems, since if a constant name contains non english characters it would break. IMHO the best implementation is to simply not lowercase constant names unless the user specifically whats case insensetive locale. the language parser should not be affected by locale settings at all, so we need a locale independant zend_str_tolower() function or make sure we have 'C' or 'POSIX' locale this does not only affect constants but also function names and unless we are going to roll up the complete case sensitivity threads *again* rolling our own tolower() function instead of using the one in libc is the only way to go IMHO PS: IMHO we have to rethink the complete set_locale() stuff in PHP as there is absolutely no way to make it work in threaded SAPIs :( Doesn't work, simply not true. My PHP code uses locales extensively and it works just fine on Apache 2.0 (threads model) and on IIS, which uses threads. ok, bad wording Sure set_locale() *works* for threaded environments, but it sets the locale globaly for *all* threads, while it should the current PHP thread only. Even worse: setting the locale may affect other components within the webserver totally unrelated to PHP (or trigger the now known tolower() and strtod() problems in other PHP threads, leading to wrong parser behaviour) just imagine an ISP hosting a threaded server for international customers or a big multinational company (or even a small one with multi-lingual web pages) where a lot of scripts running in parallel use set_locale() - each of them overwrites the current locale for all the other runnning scripts ... GOTCHA -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 H.A.R.T.M.U.T.: Hydraulic Artificial Replicant Trained for Mathematics and Ultimate Troubleshooting -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia A. wrote: Well, that is true for any external variable not just locale. For example if you export TZ variable in a threaded enviroment all threads would be affected. Exporting a TZ would be even more dangerous since it would affect a commonly used data, dates, which are used in majority of PHP script. messing around with the process environment is one thing, using an official PHP function is a different story ... I do not see how this issue can be resolved, unless PHP does some internal enviroment variable tracking as well as internal locale tracking. environment variable tracking is not needed, PHP has just to implement its own versions of locale dependant functions, track requested locale internaly as a thread variable and leave the global locale setting alone there are about 20 functions that need changes applied, most of them just use toupper()/tolower() or ctype is***() functions which can easily be replaced only things like printf(), scanf() and strftime() are a bit more difficult. For printf() and scanf() we already have our own versions that we just need to modify, and for strftime() we should bundle our own version anyway, as there are way to much problems with esp. windows users not knowing (and not reading in the docs) that not all of strftime()'s format placeholders work in every strftime() implementation i've already assigned this to me as a task for this weekend, maybe i'll find time to publish a small RFC/Whitepaper about the issues at hand tomorrow (detailed description of planned changes, affected functions, list of bugs that will be solved by the changes ...) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 H.A.R.T.M.U.T.: Hydraulic Artificial Replicant Trained for Mathematics and Ultimate Troubleshooting -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] regarding bug #12647 - should sprintf(%f, ...) be locale-aware?
it is in C, using the decimal point settings from current locale instead of just always '.' i have patched formatted_print.c to be aware of this but i'm not yet sure about the BC consequences ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mime_magic broken in CVS?
Magnus M wrote: Is mime_magic broken, or am I doing something wrong ? fixed in CVS i hope (ZTS issues... :( ) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 Wir stellen für Sie aus, auf der INTERNET WORLD in Berlin. Besuchen Sie uns vom 4. bis 6. Juni 2002 in Halle 4.2, Stand A9 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libesmtp (Was: Re: [PHP-QA] Improvement suggestionsfor mail() delivery problems)
dreamnigif it only supported win32/dreaming -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 Wir stellen für Sie aus, auf der INTERNET WORLD in Berlin. Besuchen Sie uns vom 4. bis 6. Juni 2002 in Halle 4.2, Stand A9 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #16838 Updated: PHP short_open_tags and ?xml.. ?
Markus Fischer wrote: By all means, this is completely insane :-) Have you seriously thought about what this sentence means? This would break 99% of the scripts, but I bet you had that in mind ? :) no, it isn't if it is an E_NOTICE warning it would break exactly as many scripts as undefined variables or array-indices and unquoted strings break and even if it was an E_WARNING it should not harm as in production environment you turn of display_errors and in developement environments i *want* this displayed ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed additional behaviour of str_replace()
Mårten Gustafsson wrote: Ehrm. I should probably read through the entire manual, every day :) wouldn't help in this case, the optional behavior of strtr() is really hard to find (even i as a member of a doc team and parttime german manual translater found it only by chance), we should try to find a better name for it ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] what does is happening to the list
Daniel Lorch wrote: Could someone ban this guy from php-dev? Georg I wrote him a nice and friendly mail. I hope he understands us finally as he appears to be having language problems. have tried that in every possible way i could think of without any result if he really has *that* big language problems that he doesn't get the you are using the wrong list messages sent to him for month now he won't read any sense out of the answers to his actual questions either, so ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] what does is happening to the list
Eduardo Melo wrote: What is happening to the list ... No body anwser ... I will be waiting for some contact. we are finaly ignoring you as you are neither able to switch of HTML (as requested) as anybody else does nor understand the concept of which list is which (by crosposting to php-general *and* dev) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed additional behaviour of str_replace()
Mårten Gustafsson wrote: Is there anyone else than me that would find it useful to be able to do: [...] have a look at http://php.net/strtr -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] panda pdf
Dennis Heuer wrote: I just wanted to vote for the support for the Panda PDF lib in PHP. The other libs are both not really free, the licenses aren't that nice. Panda PDF is GPLed. I swear, I am not affiliated with the developers ;) how does it compare feature-wise ? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mbstring a standard module
Yasuo Ohgaki wrote: mbstring is stable including mbregex feature. Since it was avialable as 3rd party module for a long time. that was what i thought about ext/ctype remember what it did to MacOS/X when i finaly enabled it by default? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: aggregate() und overload()
Yasuo Ohgaki wrote: --disable-experimental-aggregate and --disable-experimental-overload? Just in case we really want to make it optional and have new way for overloading/multiple inheritance. We can document these features as EXPETIMENTAL as long as we want, right? which brings us back to the discussion that EXPERIMENTAL stuff should not be packed into releases or should at least be disabled by default (like linux configuration does with its enable experomental stuff which is disabled by default) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: Session patch
Egon Schmid wrote: If you know the conference paper from the last PHP Kongress in Cologne, you can see the company logo at the page of Hartmut´s abstract :) He really dislike such a advertising himself. Please stop citing me out of context. No, i didn't dislike the advertisement. Yes, i did dislike the patent issue itself. Yes, i did dislike the placement of the add in the conference material which seemed to imply that especially my talk and my person were sponsored by 7val, although they were sponsoring the event in general and their logo just ended up on 'my' page by pure chance. What i really disliked was not even the placement of the advertisement itself but the fact that a lot of people asked me about my relation to 7val all day... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failure in mime_magic
build fixes will go to CVS any second now ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] AUTOLOAD in PHP
S.Murali Krishna wrote: Hi, As I told in my Previous Post that I have added a feauture in PHP which is similar to AUTOLOAD feauture in Perl Modules. I had sent a unified diff output along with this. According to that if a user tried to call a undefined function, PHP Zend Engine would search for a function named '__autoload' in current scope, if it finds one, it would set the global variable $php_undef_func_name with name of the called function and call the __autoload() function with passed arguments. Its working fine for me. If it seems to be good, we could discuss on this. please have a look at the callback mechanism for unserialize() ( http://php.net/unserialize ) and try to follow the scheme already implemented for including files for undefined classes on demand -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 snmp ext
Hunter, Ray wrote: I am trying to build the php_snmp extension on my windows box and it says that I am missing the php.h file. Where can I find this header file? on UNIX it gets installed into /usr/local/include/php/main/php.h and standalone extensions configure scripts use the php-config script that gets installed into /usr/local/bin/php-config (or whatever path prefix you installed to instead of /usr/local) on Windows you have to configure Visual Studios include pathes yourself, the file you are looking for is located in the php4 sources in php4/main/php.h (just wondering: doesn't windows have a search function anymore?) PS: please, please, please do yourself and others a favour and stop polluting lists with useless HTML markup, unless you feel fine with being ignored by a growing number of people -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possible Cookie Bug
Andy Woolley wrote: Ok, I hear what you are saying and accept that it isn't a bug but is it not possible to populate the cookie variable when you set the cookie. I have had many problems with cookies PHP in the past, usually due to the way they work and so anything that can be done to make cookies easier to use would be of benefit. wouldn't you be better off with php sessions instead of putting stuff into cookies yourself? If I use JavaScript to manipulate cookies, as soon as the cookie is set I can access it and I would imagine this behaviour to also be present in PHP and as it is not, it causes much confusion. JavaScript is executed on client side, PHP runs on the server side important difference in this case I appreciate that this is not of prior importance but I've just spent quite a long time trying to figure out why my cookies were not behaving as they perhaps should have. As Sander pointed out from the manual Cookies will not become visible until the next loading of a page that the cookie should be visible for.. I think this could do with being looked into at some stage. I personally think the cookie should be available as soon as it is set. a cookie is transfered to the clients browser using a Set-Cookie: line in the HTTP response header you do not know in advance if a client will accept cookies, and the client will only return the cookie on the next request (if at all) so it perfectly makes sense that a cookie is *not* visible in the php script it is first set in automagicaly setting the value in $_COOKIE[] or even as a global variable with register_globals=on would cause more confusion than it would help again: please try to understand how the HTTP protocol in general and especialy the Cookie mechanism work for cookie specification see http://www.netscape.com/newsref/std/cookie_spec.html (as mentioned on http://php.net/setcookie) for HTTP 1.1 see http://www.w3.org/Protocols/rfc2616/rfc2616 -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ctype enabled by default
[EMAIL PROTECTED] wrote: On Fri, 8 Mar 2002, Dan Kalowsky wrote: Hello PHP Dev! I'd like to request that ctype be disabled by default instead of a recently done enabling by default. Especially for the 4.2 release. +1 for this, Dan, are you going to do this? please let me have at least one chance to fix it ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ctype enabled by default
Dan Kalowsky wrote: Hello PHP Dev! I'd like to request that ctype be disabled by default instead of a recently done enabling by default. Especially for the 4.2 release. Mainly because it seems that MacOSX does not like the way things are being done, claiming that each ctype (i.e. isalnum, isalpha, etc) is an undefined variables. it is now implemented using a MACRO instead of function pointers, this should make it work even on MacOS/X? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Get object name
l0t3k wrote: you can do this only with a not-so nice hack. essentially you have to manually search the active symbol table stack for a zval * which equals your variable. zend_hash_find wont help you, since you're doing a reverse lookup. ... and your chances of getting the right name in case of assignments by reference are 50/50: ?php $a = new obj(); $b = $a; $a-print_obj_name(); $b-print_obj_name(); ? reuslt will be either a a or b b but not a b -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Variable name?
Walter A. Boring IV wrote: Howdy, I was thinking about tweaking the var_dump/print_r functions to provide the name of the variable being dumped. Is there a way to look that up? from the active_symbol_table-- ? ?php $a = something; $b = $a; // $b refers to the same zval as $a print_r($b); // function gets only the zval reference // how should it be able to find out if you // passed $a or $b ? ? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch to extract()
Richard Heyes wrote:
Anyone interested in this patch?
not really, i'd use foreach and unset on the array before
extracting, far less obfuscated than the callback approach
or, if the array should not be modifiert:
function callback($value, $key) {
if(preg_match('/^var/', $key)) {
$GLOBALS[$key] = $value;
}
}
array_walk($array,callback);
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns
in Halle 6 auf Ihren Besuch am Stand H 18
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SAP DB
Lukas Smith wrote: Yes, As I didn't know that SAPDB = AdabasD I was unaware... As far as I know is is pretty much AdabasD but ist not exactly AdabasD either. Its basically a fork from all I know. that's why i wrote from a programmers point of view SAP has bought the right to use the AdabasD Source Code from SAG a while ago (SAG AdabasD is one of the few SQL Databases you can run SAP R/3 on, and it was the first of the 'big players' databases to be ported to Linux, way ahead of Oracle and Informix). The idea behind the whole SAP DB stuff seems to be to have an alternative to Oracle around, jsut in case ... ;) SAP DB and AdabasD are now seperate products and the code bases have forked, but SAP and SAG still work together so it is very hard to distinguish the two products from one another. They are far more similar than eg. the Sybase and Microsoft servers have been in the 90ies AFAIK the original codebase for SAP DB was AdabasD 6.x, while current AdabasD version is 11.x, but the differences from 6.x to 11.x are not as big as the version numbers suggest, and a lot of stuff added to AdabasD after 6.x should have been available to SAP developers, too -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SAP DB
alex black wrote: hi all, One of the binarycloud developers just told me to have a look at the SAP OS database, SAPDB. SAP DB is just another name for AdabasD from a programmers point of view- I'm going to test it tomorrow to see if it actually does what it claims, but this _looks_ like serious OS competition to Oracle, and if it is I would very much like to use it for my next project. So, question: Has anyone used SAPDB with PHP? If so, experiences? And if not, are there plans for drivers? I looked in the manual and I didn't see any mention of SAPDB. http://www.php.net/manual/en/ref.odbc.php Oh, and I just found a mention of PHP on the SAPDB site. Looks like the connection is over ODBC, which I really _really_ dislike... are there plans for anything native? like a sapdb_connect :)? from the link mentinoned above: In addition to normal ODBC support, the Unified ODBC functions in PHP allow you to access several databases that have borrowed the semantics of the ODBC API to implement their own API. Instead of maintaining multiple database drivers that were all nearly identical, these drivers have been unified into a single set of ODBC functions. so the call interface to AdabasD/SapDB looks like ODBC, but you have direct access to the database using PHP, you don't have to deal with ODBC driver management and all the stuff if you don't want you In any case I think this database has a _HUGE_ amount of potential and PHP would benefit if access to SAPDB was possible. as said above: it is all there ... just the documentation could need a little update ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: CLI and php.ini
Yasuo Ohgaki wrote: I would like to have different file name for cli config file by _default_ also. i'd prefere conditionals in php.ini something like IfModule ../IfModule in apache config, maybe IfSapi cli.../IfModule ? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: CLI and php.ini
Robinson, Mike wrote: IMHO, conditionals in one php.ini file would have a huge WTF factor on newbies and Joe User. newbies do not care about php.ini anyway ;( now serious: most of the php.ini settings will be equal for both, so why bother with two files (and keeping them in sync) when the same can be done in one file? if works nice for httpd.conf I like the php-cli.ini idea myself. we could still have a 2nd configure option for setting a different php.ini path for cli ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
Yasuo Ohgaki wrote: I guess the original reason why PHP has case insensitive class/function names is consistency with HTML standard. If so, XHTML _is_ case sensitive, we should go for case sensitive names. [...] Question is, PHP is going to be nice to other web related technology or not. I hope most of users answer 'yes' for this :) XHTML being case sensitive was no design decision, it just 'happend' as XML is (and the decision whether XHTML tags should be upper or lower case took quite some time) for XML the decision to be case sensitive made sense, for XHTML it doesn't (or does it have any TAG/Tag/tag variants in it?), it just hat to be so to be XML compliant php doesn't have to be XML compliant, so i can't see the point in the XHTML argument regarding other web related technology (i don't really like the term 'technology' in this context, but that is a different story) IMHO case preservation is all we need i'm not very familiar with current Java coding style/guidelines, but from what i remember nobody really made use of the fact that java IS case sensitive but i *do* remember that we did curse badly about having to remember where to use this long forgotten shift key when typing class and method names -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
Yasuo Ohgaki wrote: It will be confusing PHP preserve case for other while internally case insensitve... exactly as confusing as the file systems 90+% of computer users (Win+MacOS that is) are used to ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
Yasuo Ohgaki wrote: To use file system as a user, there is no logic required. (I mean control structures are not needed to use files) I guess Java/C/C++ is very popular and serious programmers know at least one of them. Chances are high that new users get confused by PHP after learnning Java/C/C++. I think students learn Java/C/C++ in a university rather than PHP :) how many ut these make actualy *use* of the case sensitivity these languages provide (other than cpp #define CONSTANT)? Anyway, if we stay in with current case insensitive names, I think we should not have case preserved names for other technology. could you elaborate on that? either i am completely stupid or this argument is complete nonsens ... If we are willing to be nice to other technology, we should go for case sensitive names, IMHO. it is not about being nice to other technologies (once again, i don't like the term technology in this context), it is about being compatible with external interfaces while being nice to users meeting their expectations regarding bc and convenience -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
Yasuo Ohgaki wrote:
Case of names can be easily converted by program.
do you think it will be easy in this situation?:
?php
function myCompare($arg1,$arg2) {
}
[...]
$sorted_array=usort($array,myCompare);
[...]
$sorted_array=usort($array,mycompare);
[...]
?
and, by the way: what kind of a program is going to convert this?
a shell script? what about windows users?
a php script? what about users that just want to install a product
written for php 4 in a php 5 environment where they do not have
any shell access or where no php cli is installed?
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns
in Halle 6 auf Ihren Besuch am Stand H 18
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #14455 Updated: Warning: Undefined variable: Version for win98
[EMAIL PROTECTED] wrote: i have the same problem. when i first time using xitami as a web server. the codes like that is fine. but when i go to apache web server. it occurs an error. why is it happen??? different error_reporting settings in php.ini -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Case sensitivity: Conclusion(?)
Yasuo Ohgaki wrote: Case of names can be easily converted by program. do you think it will be easy in this situation?: I'm well aware of cases auto conversion is difficult. thats not what can be easily converted implied ... and, by the way: what kind of a program is going to convert this For windows, it's just a matter of downloading php.exe if it's written in PHP, isn't it? windows users do not like command lines ;) It's easy/intuitive to know where to look/fix function not found error, if scripts were working under PHP4 :) it is for you and for me, but our average user is well below our level :( look at all the user questions and bug reports regarding things like can't send header ... output already started at ..., notice: undefined variable or notice: undefined constant xyz, asuming 'xyz' instead a lot of people do not read error messages, they just see that something does not work as it should and with my example of callback functions it usualy isn't even clear where the actual error is due to the additional level of indirection Zeev: btw., what about my undefinde function ... maybe you were looking for ... instead? patch? could be extended to look for case-only differences before performing the levenschtein comparison *if* we switch to case sensitivity so we at least had a better error messge even if people don't read it ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple for you, not for me
Ramin Berwers wrote: Hi, A simple question for you, but I can not find the solution. My source: ?php include(http://204.227.127.33/awc/fltfldr/6443.txt;) ? The result: http://www.sportvliegen.nl/test.phtml If you watch the original document: http://204.227.127.33/awc/fltfldr/6443.txt I would like to have the original document in my HTML-code. Does you have the solution? Please, email to [EMAIL PROTECTED] with your answer. Thank you very much, Ramin Berwers use readfile instead of include -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] general support questions on the dev list
seems like a lot of these messages get here not by search engine results as i thought but due to the news.php.net nntp server would it be possible to replace the list addresses in the message headers mirrored to the news server by just their name without '@lists.php.net' or something? that might help a bit putting the actual lists in a more prominent place on the support page while moving the news stuff a bit down might help, too -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion: Wrong-list-link
Daniel Lorch wrote: there are a bunch of links at the bottom of this page. but how about a Sorry-this-is-the-wrong-list-for-this-kind-of-question-please-go-to php-general-link which also automatically sets it to bogus? what do you think, guys :) right now i'm more interested in investigating what makes these people ask here in the first place then just telling them to 'go away' -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion: Wrong-list-link
Daniel Lorch wrote: I'm quite sure this is because of the ambiguity of the term PHP development. Also, not-so-skilled developers obviously are not able to differentiate between real bugs and user errors. And there's nothing you could change about the latter. yes, but where do they find the list address in the first place? php-dev is way down in the list of lists on php.net, hidden between other lists rather obscure to the averatge user, while php-general is at the top. i don't think this is the place where they find it ... my two current theories are search engines and the news server especialy the news server as php-dev is almost at the top there as -dev is alphabeticaly before -general ... anyway, i'd like to know the cause instead of just dealing with the symptoms. a automatic reply link won't be kind, no matter how polite the text it sends is, unless something makes sure the user gets this automatic reply only once per message -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Lists
John Donagher wrote: This has probably been mentioned before, but I think the naming of php-dev is way misleading. It's funny that people get so ripped when someone sends an off-topic question to this list. Someone who doesn't read the descriptions may very well take php-dev to mean PHP development. This is ambiguous; it doesn't make any distinction between developing with php and developing the language itself. Whining about people not reading the descriptions won't change it; get over it. These messages most likely do not come from people who have looked at the php.net list of lists at all, as the dev list is hidden way down while php-general is in a *much* more prominent place. My theory is that these messages come from people who have found the list address in archived messages while searching for php related topics using a search engine. We have the same effect on the php-lang list which isn't even advertised at all on php.net. So i guess renaming the dev list would only help for a short period of time, while mandatory subscription via the php.net support pages is the only way to get rid of this special problem. -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Marc Boeren wrote: +1 for case-sensitive everything so you volunter to rewrite all the code that uses oci or gd extension now but uses it all lowercase? ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Marc Boeren wrote: +1 for case-sensitive everything so you volunter to rewrite all the code that uses oci or gd extension now but uses it all lowercase? ;) I didn't say +1 for lower-case everything! (although that is my preference, for functionnames at least ;-) oci and gd extensions had mixed-case names for ages, but you see both mixed- and all-lower case usage all over the place now no matter how the function names themselves will be in the future, case-sensitivity will break app. half of the existing code using them we've been fighting about backwards compatibilty issues far less critical than this and usualy have decided to keep bc where possible until it really does hurt to much, all these efforts would become useless if we introduced a bc breaking change as far reaching as this just for cosmetic/esthetic reasons ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
Yasuo Ohgaki wrote: Andrei has been wrote conversion program. I don't know the details, but it may do better job than making all to lowercase (?) will it also detect and rewrite the usage of function/method names in strings used for eg. callback handlers? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- 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/msession msession.c
[EMAIL PROTECTED] wrote: We have been down this road before. There is a reasonable expectation that extensions may differ subtly from extension to extension. I see no need to fork my source for 4.0.x and 4.1.x compatibility when it is simple enough to do with macros and maintain one source file. ... and with #ifdefs all over the place it becomes a complete mess, even now with only two different api versions supported maintainance of older releases is what we have CVS branches for, we have more than enough #ifdef's in the code (due to configure detected stuff and threaded server support), i see no need to have even more of those in situations where we have other means to deal with -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ZE repositories
Zeev Suraski wrote: At 10:23 AM 2/5/2002, Derick Rethans wrote: On Tue, 5 Feb 2002, Zeev Suraski wrote: That may be trickier. License wise, it's under a different license (we're not in a position to change it, New Riders, Till and Tobias are). I also think it makes sense to keep it in a different module (like the ZE/ZE2 will, even though they'll be in the php.net CVS). The build can probably change to automatically include this into the manual, and it should be possible to note that this part is under a different OS license. The build process already works that way, but otherwise I think we just should ask New Riders if the licence can be changed is needed. It should be noted that I believe it'll be better for the manual to lose the ugly license it's under and move to the openbook license, than the other way around. But I've already done my share of license wars in my life - if you want to talk to New Riders, go ahead. agreement has been reached a long time ago that the GPL is not the right license for documentation anyway (although maybe for different reasons then what you refered to as 'ugly' ;) i hope that we be able to finaly decide on which license to switch to in march, and yes, the Open Publication License the API doc is now under is one of the few that had been suggested ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- 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/msession msession.c
[EMAIL PROTECTED] wrote: Removing backward compatibility for aesthetic reasons is bogus. To be perfectly honest, I think the whole PHP extension API is truly ugly. The removal of a few #ifdefs will not a Mona Lisa make. to me readability is a maintainance issue, not an aestheic one ... if you don't care about others to understand your code, or even don't want anyone to touch it anyway (as you already have made clear), then you really should move the extension. either from php4/ext to pear/PCL, where cross-version compatibility is sort of a point, or even to a repository of its own -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- 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/msession msession.c
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Removing backward compatibility for aesthetic reasons is bogus. To be perfectly honest, I think the whole PHP extension API is truly ugly. The removal of a few #ifdefs will not a Mona Lisa make. to me readability is a maintainance issue, not an aestheic one ... Perhaps for you it is, but not everyone agrees with you. Open source is about freedom, is it not? if you don't care about others to understand your code, or even don't want anyone to touch it anyway (as you already have made clear), I have made no such declaration. I just do not think well placed #ifdefs affect readability or maintainability. That is your opinion, not mine. I welcome anyone to add features to the msession code as they see fit. All I ask is that they do not remove backward compatibility. This is not an earth shattering request. we had several points in our last argument, and BC and #ifdef's was only one of it. for that one i had suggested to revert to the old parameter parsing style (which still works and *is* BC on the source level) instead of having it both ways, wrapped up in #ifdef OLD_ZEND_PARAM as the *only* reason for introducing the new parameter parser was readability and maintainability in the first place, while in this case you'd reached the complete opposite just for the records: it was me who put in the final missing piece to make it all 4.0.6 compatible again in rev. 1.15 of msession.c and this time you've hit a nerve by reverting a patch needed for current dev version in favour of 4.0.6 compatibility AFAIK sure, backwards compatibility is a nice to have, but it's not our primary goal as far as extension source code is concerned I am really tired of this argument. Why do you care? Why does anyone care? The code is fairly readable, it doesn't do anything hard to understand. It is a simple thunk/trasport layer for another library all together. If anyone has trouble reading or understanding it, I would suggest that they need to take a basic C class. even for a coder it is not always easy to adopt his mind to different coding styles in otherwise similar pieces of code and to untangle nested conditionals but we do not only have coders on this project, but also people doing the documentation that might not be so fluent in C or might not even code C at all thats what we have the proto comments for, and the new parameter parser API was ment to make it easier to verify that a given proto comment matches the actual paramter evaluation, besides other issues More over, I think msession, while still a bit experimental, is a worthwhile addition to PHP. I already have a few people using it and it has helped them deploy their web farm. People are using it, and in doing so people are using PHP for big things. As I understand it, this is what we all want, right? it would be even more usefull if people knew it was there and how to use it (ooops, i'm slightly shifting to a different topic) that's why i added the proto comments (which i then used to generate the skeleton xml documentation file currently in the manual), which lead me to the other changes back then ... nothing would have happend to your code if it had been compliant with the guidlins layed down in README.CVS-RULES and other places (at least from my side) if you had followed at least the proto-comment recommendation I think very highly of PHP. It is a great project. I submited my extension to add value to the project. I think it can add value and help moderately large installations. All I am asking is that, as one developer, that backward compatibiliy remains so I do not have to maintain two branches and duplicate work. My time is valuable, why should I waste it? as long as a CVS release branch is 'active', changes you want to have in that release branch would have to be applied there anyway if we ever decide to have a 4.0.6pl# or 4.0.7 maintainance release for whatever reason, you would find the extension bundled with that release lacking all the features you added to the main dev branch now, no matter how much effort you'd put into keeping the dev branch BC so why not applying your patches to both branches in the first place? This is not a lot to ask and I simply do not understand what the problem is. In any professional environment, this would be a no-brainer. You do not remove backward compatibility if you do not need to do so. but on the other hand there is no reason to have BC in mind on the source level if you have already dealt with that issue on another level (here: version control system) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- 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/msession msession.c
[EMAIL PROTECTED] wrote: I wrapped the new parameter stuff in the #ifdef/#else/#endif because someone had put some work into it. I did not wish to remove someone else's effort. effort appreciated, but you kept a cosmetical part of my while dropping the functional one, the proto comments that get evaluated by various documentation tools just for the records: it was me who put in the final missing piece to make it all 4.0.6 compatible again in rev. 1.15 of msession.c Thanks. just to show that i don't completely ignore the BC issue ;) and this time you've hit a nerve by reverting a patch needed for current dev version in favour of 4.0.6 compatibility AFAIK What did I revert? What did I remove? If any functionality was removed, it was an error on my part. I had some local changes that I wanted to check in, and I needed 4.0.x compatibility so I could use it on my site. sure, backwards compatibility is a nice to have, but it's not our primary goal as far as extension source code is concerned This sort of bothers me. Who is this our you talk about? As contributor of the msession extension, am I not also part of our and don't I get a say on the priorities of msession? not if these priorities are in contradiction to the overall goals, and as such BC is not *that* important on a developement branch I can understand your position, but the msession extension not a difficult peice of code. I have updated the proto comments so they correctly state what the functions do. Just tell me what else you want for comments. the #ifdef OLD_ZEND_PARAM stuff obfuscates it without need, especially in the additional places where you use it like this #ifdef OLD_ZEND_PARAM php_log_err(Call to connect with non-null s_conn); #else php_log_err(Call to connect with non-null s_conn TSRMLS_CC); #endif the behaviour you test for is not at all related to the parameter parsing functions, its just by coincidence that both are related to the same api version number switch -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tabs Vs Spaces (and other coding styles)
James Cox wrote: have we ever decided on this? in our code do we go for tabs or spaces? Is there a style guide anywhere on this? see php4/CODING_STANDARDS: [...] [4] When indenting, use the tab character. A tab is expected to represent four spaces. It is important to maintain consistency in indenture so that definitions, comments, and control structures line up correctly. [...] maybe we should add indent-tabs-mode:t to all the emacs options footer comments? -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] NEW PHP standalone compiler (was Re: [PHP-DEV] Here we try again)
Sam Liddicott wrote: have you had a look on php4/Zend/LICENSE lately ? ;) No I checked the one on the web site, url provided at the time, but you could stop playing games and get to the point. [goes off to check] I'm not sure which file you meant by that file. http://cvs.php.net/cvs.php/php4 LICENSE 1.17 imajes 3 daysupdating license to 2002 (hasn't been done since 2000) Not version 1.5 or 1.6 and no significant changes. so you were looking at the wrong file http://lxr.php.net/source/Zend/LICENSE The Zend Engine License, version 2.00 (as of CVS version 1.6, Dec. 4, 2001) the license is no longer the QPL that http://www.php.net/license/ZendGrant/ZendGrant3.png and ZendGrant4.png are refering to, so your argument and your reference to section 5a of the old license doesn't apply to the current situation anymore that's why i asked if you had a look at the actual LICENSE file (the one in the Zend part, not the toplevel php4 LICENSE file) have you had a look on php4/Zend/LICENSE lately ? ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
Ivan Ristic wrote: Also, ISPs (like AOL) who use farms of proxy caches will change a users apparent ip during a single session. (i.e. concurrent requests may come from different ips). The real IP address can be tracked in most cases (say, using the HTTP_X_FORWARDED header an others) but I am not really sure that we should put the logic for that in the PHP engine itself. Users can add the additional PHP code to their libraries. Anyway, you can change the session id from the PHP code itself. Still the IP of the client can change every once in a while when his DHCP lease expires ... or when they use dial-on-demand and automatic hangup as eg. provided by the linux ISDN subsystem? Do you really want client sessions to become invalid every time their ISP decides to assign them a new IP? For my system at home this could make a service unusable as it automaticly hangs up the ISDN line after 60sec without IP traffic and redials on demand (with ISDN you have connect times of 1sec, so you don't even notice you've been disconnected, but you'll notice the effect on the bill if you are charged by connection time). So my Client IP might even be different for every single request if it takes me more than a minute to read a page or fill out a form ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
