Re: [PHP-DEV] Re: mbstring
On Tue, 3 Sep 2002 07:13:41 +0100 James Cox [EMAIL PROTECTED] wrote: I think that the problem is caused by --enable-mbstr-enc-trans option and is not caused by mbstring itself. If --enable-mbstr-enc-trans is enabled, php_treat_data, the original handler of user input (POST/GET/Cookie), is overrided by mbstr_treat_data in ext/mbstring , the multibyte enabled version. mbstr_treat_data had a GET handling bug in PHP 4.2.x/PHP 4.1.x. Although the bug was already fixed in CVS, but mbstr_treat_data is not used by non multibyte user. So, I abolished --enable-mbstr-enc-trans option in CVS, and made a new php.ini option 'mbstring.encoding_translation', which is the equivalent of --enable-mbstr-enc-trans, and which is 'Off' by default. so this is now always on, but controlled by an ini variable? that doesn't sound very good. maybe i'm being paranoid, but it seems to me that you've just enabled it by default (at build time). No, this option is 'disabled' by default, and can be enabled by a ini variable. mbstring.encoding_translation = Off; is default. If mbstring.encoding_translation = On is set in php.ini, the transparent conversion will be enabled. I think the user input (POST/GET/Cookie) related problem for non-multibyte user will completely disappeer with this change. And, the mbstring should be 'enabled' by default. I18N of PHP is very important for especially multibyte PHP users. [snip] I agree with Zeev, the simplicity of development work is important. So, the duplicate code of the user input handler should be merged with the original handler in PHP 5.0. I agree -- it's very useful.. but i don't think it should exist as an extension, but built in.. the extension just now seems a really messy way of doing it. Yes, I think mbstring is very fundamental feature and it should be built-in feature (in PHP 5.0). But, string related functions and some other core functions are included in ext/standard which is also in extension part. Rui -- - Rui Hirokawa [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: mbstring
No, this option is 'disabled' by default, and can be enabled by a ini variable. mbstring.encoding_translation = Off; is default. If mbstring.encoding_translation = On is set in php.ini, the transparent conversion will be enabled. ok, but before, you had to --enable it before it'd work? or did it get built _EVERY_ time regardless? [snip] Yes, I think mbstring is very fundamental feature and it should be built-in feature (in PHP 5.0). But, string related functions and some other core functions are included in ext/standard which is also in extension part. sure, ext/standard works... we just need to lose the duplication. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Default extensions (was: mbstring)
At 00:19 03/09/2002, James Cox wrote: i still don't see why we shouldn't just disable everything by default and write a 'default configure' script... Because other than a WFF of 'purity', it gains nothing and loses lots. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: mbstring
On Tue, 3 Sep 2002, James Cox wrote: No, this option is 'disabled' by default, and can be enabled by a ini variable. mbstring.encoding_translation = Off; is default. If mbstring.encoding_translation = On is set in php.ini, the transparent conversion will be enabled. ok, but before, you had to --enable it before it'd work? or did it get built _EVERY_ time regardless? Does it matter? ini settings are much easier to notice during debugging than #ifdefs, so I think Rui made an excellent choice here. However, some documentation of these settings would be useful (hint :). [snip] Yes, I think mbstring is very fundamental feature and it should be built-in feature (in PHP 5.0). But, string related functions and some other core functions are included in ext/standard which is also in extension part. sure, ext/standard works... we just need to lose the duplication. You obviously have no idea what mbstring exactly does, as this comments makes little sense. mbstring _overloads_ functions which are in ext/standard (such as strpos() ). That is a little bit too much magic, and thus I like to see the mbstring functions merged into the ext/standard functions (for PHP 5). Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: mbstring
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 03, 2002 7:51 AM To: James Cox Cc: Rui Hirokawa; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Re: mbstring On Tue, 3 Sep 2002, James Cox wrote: No, this option is 'disabled' by default, and can be enabled by a ini variable. mbstring.encoding_translation = Off; is default. If mbstring.encoding_translation = On is set in php.ini, the transparent conversion will be enabled. ok, but before, you had to --enable it before it'd work? or did it get built _EVERY_ time regardless? Does it matter? ini settings are much easier to notice during debugging than #ifdefs, so I think Rui made an excellent choice here. However, some documentation of these settings would be useful (hint :). well, the mbstring-enc-trans stuff is what seems to have caused the issues before, so having it built in might not be a great idea. Besides, it just increases the base binary size, which makes life harder for people trying to embed php. [snip] Yes, I think mbstring is very fundamental feature and it should be built-in feature (in PHP 5.0). But, string related functions and some other core functions are included in ext/standard which is also in extension part. sure, ext/standard works... we just need to lose the duplication. You obviously have no idea what mbstring exactly does, as this comments makes little sense. mbstring _overloads_ functions which are in ext/standard (such as strpos() ). That is a little bit too much magic, and thus I like to see the mbstring functions merged into the ext/standard functions (for PHP 5). Sorry, that's what i meant: to move ext/mbstring overloading stuff into it's rightful place, rather than duplicating the code. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.2.3RC2
On Monday 02 September 2002 9:10 pm, [EMAIL PROTECTED] wrote: done 2 :) The page still hasn't updated itself from CVS - is something somewhere not running? -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA]4.2.3RC2
On Tue, 3 Sep 2002, Phil Driscoll wrote: On Monday 02 September 2002 9:10 pm, [EMAIL PROTECTED] wrote: done 2 :) The page still hasn't updated itself from CVS - is something somewhere not running? At the moment there is a lot not running, try bugs.php.net for example... *sigh* Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
Best regards Andrey Hristov - Original Message - From: James Cox [EMAIL PROTECTED] To: Jani Taskinen [EMAIL PROTECTED]; Jon Parise [EMAIL PROTECTED] Cc: PHP Development Mailing list [EMAIL PROTECTED] Sent: Tuesday, September 03, 2002 12:19 AM Subject: RE: [PHP-DEV] Default extensions (was: mbstring) Unfortunately we don't live in a perfect world where sysadmins know how to read and listen to their users requests. That's why mysql for example is enabled by default. (or that's the main reasoning behind it at least) And we can't educate people or force them to anything either. Maybe we should add a general '--disable-all' option? i'm +1 for that if it means that first it disables everything, and then you enable stuff bit by bit... --disable-all is good for me for one reason - to speed dev builds. When I work on arrays I don't want to link xml, mysql and so on. I've disabled them in config.nice but --disable-all is better because it won't be needed to search which modules I can disable. --disable-all can be good for some sysadmins that run large websites and want to have only that they need - disabling all and adding what is needed thus decreasing the size of the binary. The idea about ncurses based setup is very good and I hope we will found the man/men who will do it. On the other hand it won't be good if mysql is disabled by default. I saw one reason here : endless bug reports about mysql_connect() more than these about Apache2 builds. Another reason : mysql is easy to install on most platforms (mostly windows) and because PHP is easy to learn (good curve) - PHP is the choice as the language to write scripts. Also I think that enabling postgresql support by default will be good. Thus we will provide support not only for one database in the builds. Mysql is overpromoted and PG stays in the dark (this is my opinion). Regards, Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: mbstring
On Tue, 3 Sep 2002, James Cox wrote: lets summarize what we got out of this... -- mbstring is a very useful part of PHP and should be integrated properly into ext/standard . Not in ext/standard, but just plain the the core. It is not NEW functionality, but just enhances existing ones. -- mbstring-enc-trans has some issues, but that's ok because you can't disable-and-not-build it at build time now There are no issues anymore that are known. -- having default packages is ok, but we need some method of being able to 'clear' the list (or enable them all) Jani has this working but it needs some testing IIRC. -- we need some kind of documentation about default packages... I might be able to spend some time on that. erm, that can be done with the line that Melvyn posted to php.qa some time ago: http://news.php.net/article.php?group=php.qaarticle=5899 Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
On Tue, 3 Sep 2002, Andrey Hristov wrote: i'm +1 for that if it means that first it disables everything, and then you enable stuff bit by bit... --disable-all is good for me for one reason - to speed dev builds. When I work on arrays I don't want to link xml, mysql and so on. I've disabled them in config.nice but --disable-all is better because it won't be needed to search which modules I can disable. --disable-all can be good for some sysadmins that run large websites and want to have only that they need - disabling all and adding what is needed thus decreasing the size of the binary. yes, and as I pointed out Jani got this almost working. The idea about ncurses based setup is very good and I hope we will found the man/men who will do it. Yeah, it's nice... but no time :) On the other hand it won't be good if mysql is disabled by default. I saw one reason here : endless bug reports about mysql_connect() more than these about Apache2 builds. Another reason : mysql is easy to install on most platforms (mostly windows) and because PHP is easy to learn (good curve) - PHP is the choice as the language to write scripts. Also I think that enabling postgresql support by default will be good. Thus we will provide support not only for one database in the builds. Mysql is overpromoted and PG stays in the dark (this is my opinion). Well, for something to enable by default you need to bundle the library, and I don't think it's a good idea to bundle another RDBMS client library... Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] array_unique broken?
bugs.php.net seems to be down, so i do it this way: ah. and 4.2.3RC2 and Compaq Tru64 are'nt mentioned on buildtest-submit on qa.php.net When running array_unique over Array ( [0] = 1 [1] = 1 [2] = 1 [3] = 2 [4] = 2 [5] = 3 [6] = 9 [7] = 7 [8] = 4 [9] = 4 [10] = 4 [11] = 4 [12] = 4 [13] = 4 [14] = 4 [15] = 4 [16] = 5 [17] = 12 [18] = 12 ) PHP 4.2.3RC2 on Compaq Tru64 returns Array ( [0] = 1 [3] = 2 [5] = 3 [6] = 9 [7] = 7 [13] = 4 [16] = 5 [18] = 12 ) should'nt it be Array ( [0] = 1 [3] = 2 [5] = 3 [6] = 9 [7] = 7 [8] = 4 [16] = 5 [17] = 12 ) ? Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] array_unique broken?
Hi, I am not too much in array_unique() but played with array_diff() for a week to implement array_diff_assoc() with no success so far but atm I am dreaming the code of array_diff. I saw that most of the code of array_diff() is in array_intersect() and probably in array_unique() (yup it is like them). The argument is sorted with zend_qsort() by value and nothing is known for the key order in the sorted array. Then the array is traversed from the beginning to the end and when two or more sequental elements are equal everything starting the second equal is wiped (in the result that is returned). Best regards Andrey Hristov - Original Message - From: Sebastian Nohn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, September 03, 2002 10:39 AM Subject: [PHP-QA] array_unique broken? bugs.php.net seems to be down, so i do it this way: ah. and 4.2.3RC2 and Compaq Tru64 are'nt mentioned on buildtest-submit on qa.php.net When running array_unique over Array ( [0] = 1 [1] = 1 [2] = 1 [3] = 2 [4] = 2 [5] = 3 [6] = 9 [7] = 7 [8] = 4 [9] = 4 [10] = 4 [11] = 4 [12] = 4 [13] = 4 [14] = 4 [15] = 4 [16] = 5 [17] = 12 [18] = 12 ) PHP 4.2.3RC2 on Compaq Tru64 returns Array ( [0] = 1 [3] = 2 [5] = 3 [6] = 9 [7] = 7 [13] = 4 [16] = 5 [18] = 12 ) should'nt it be Array ( [0] = 1 [3] = 2 [5] = 3 [6] = 9 [7] = 7 [8] = 4 [16] = 5 [17] = 12 ) ? Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
Jim Winstead wrote: Yasuo Ohgaki [EMAIL PROTECTED] wrote: Marcus B?rger wrote: We already had some discussion on some IF statements in ini files already. I guess we might call to another mail thread here and hope we find a volunteer. I will not invent any work here since that would be totally useless. I think having a IF in php.ini is good idea. it's too bad we don't have an implementation of a complete programming language laying around. Having IF like feature does not mean to have a new language. It could be a XML parser, for example. There could be multiple php.ini for each SAPI and user named php.ini from PHP 4.3.0. Therefore, it's not strictly required obviously. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
At 10:25 03/09/2002, [EMAIL PROTECTED] wrote: strlen() overloaded by mb_strlen might causes some problems because it is used to measure length of string and to measure length of binary data. So, a new function to measure string length only (or binary length only) will be necessary. Sure, I don't think that will be a problem. I do. strlen() should go on returning the binary length, breaking that is really a bad idea. We can introduce a new function altogether that returns the 'calculated' MB aware length, that won't cause any problems. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
On Tue, 3 Sep 2002, Zeev Suraski wrote: At 10:25 03/09/2002, [EMAIL PROTECTED] wrote: strlen() overloaded by mb_strlen might causes some problems because it is used to measure length of string and to measure length of binary data. So, a new function to measure string length only (or binary length only) will be necessary. Sure, I don't think that will be a problem. I do. strlen() should go on returning the binary length, breaking that is really a bad idea. We can introduce a new function altogether that returns the 'calculated' MB aware length, that won't cause any problems. strlen - stringlength... I think this should count the number of characters in a string, not the binary length. It would be nice if this function (strlen) would be transparent with mb things too, as no code needs to be changed then. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?
On Tue, Sep 03, 2002 at 11:04:55AM +0300, Andrey Hristov wrote: Hi, I am not too much in array_unique() but played with array_diff() for a week to implement array_diff_assoc() with no success so far but atm I am dreaming the code of array_diff. I saw that most of the code of array_diff() is in array_intersect() and probably in array_unique() (yup it is like them). The argument is sorted with zend_qsort() by value and nothing is known for the key order in the sorted array. Then the array is traversed from the beginning to the end and when two or more sequental elements are equal everything starting the second equal is wiped (in the result that is returned). The new code in CVS for array_unique() does actually (or should) always keep the first element. This was accidentally the case, at least on some platforms, before zend_qsort() was introduced because some native qsort() implementations use mergesort (at least on small datasets) which preserves the order. Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] array_unique broken?
On Tue, 3 Sep 2002, Andrey Hristov wrote: AH AH Hi, AH I am not too much in array_unique() but played with array_diff() for a week AH to implement array_diff_assoc() with no success so far but atm I am dreaming AH the code of array_diff. I AH saw that most of the code of array_diff() is in array_intersect() and AH probably in array_unique() (yup it is like them). AH The argument is sorted with zend_qsort() by value and nothing is known for AH the key order in the AH sorted array. If (zend_)qsort is the basis for all sorting operations, regarding arrays, isn't it better then to use a stable sorting routine (I don't know if zend_qsort makes qsort stable, so if it does, ignore this). From my personal experience, I expect array_unique, to display more or less the same functionality as the SQL GROUP construct, leaving the first element of dupli- cates in tact. On BSD you have mergesort() but I don't know how portable that is. -- Melvyn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
strlen - stringlength... I think this should count the number of characters in a string, not the binary length. It would be nice if this function (strlen) would be transparent with mb things too, as no code needs to be changed then. Agreed. strlen() should imho return number of characters and something like sizeof() number of bytes. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?
So the docs are right? Note that keys are preserved. array_unique() sorts the values treated as string at first, then will keep the first key encountered for every value, and ignore all following keys. It does not mean that the key of the first related value from the unsorted array will be kept. Best regards Andrey Hristov - Original Message - From: Stig Venaas [EMAIL PROTECTED] To: Andrey Hristov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 03, 2002 11:16 AM Subject: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken? On Tue, Sep 03, 2002 at 11:04:55AM +0300, Andrey Hristov wrote: Hi, I am not too much in array_unique() but played with array_diff() for a week to implement array_diff_assoc() with no success so far but atm I am dreaming the code of array_diff. I saw that most of the code of array_diff() is in array_intersect() and probably in array_unique() (yup it is like them). The argument is sorted with zend_qsort() by value and nothing is known for the key order in the sorted array. Then the array is traversed from the beginning to the end and when two or more sequental elements are equal everything starting the second equal is wiped (in the result that is returned). The new code in CVS for array_unique() does actually (or should) always keep the first element. This was accidentally the case, at least on some platforms, before zend_qsort() was introduced because some native qsort() implementations use mergesort (at least on small datasets) which preserves the order. Stig -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
On Tue, 3 Sep 2002, Zeev Suraski wrote: At 11:20 03/09/2002, [EMAIL PROTECTED] wrote: strlen - stringlength... I think this should count the number of characters in a string, not the binary length. It would be nice if this function (strlen) would be transparent with mb things too, as no code needs to be changed then. Compatibility is king. strlen() returns the number of bytes, has been for at least 5 years. You just can't change that because the name is slightly better or slightly worse. Simply stating Compability is king. doesn't do it for. And just saying that it has been like that for at least 5 years doesn't mean it can not change. It won't break BC at all (not even for the mbstring users, as the mb_strlen() overloads the 'normal' strlen(). Heck, it will even break BC for those users! Also, from the docs (and that is all what should matter to users): strlen (PHP 3, PHP 4 ) strlen -- Get string length Where can I find that it returns the number of bytes? Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
I'm going to argue about it (fiercely :) if/when it becomes more relevant, but not a microsecond sooner... Zeev At 11:38 03/09/2002, [EMAIL PROTECTED] wrote: On Tue, 3 Sep 2002, Zeev Suraski wrote: At 11:20 03/09/2002, [EMAIL PROTECTED] wrote: strlen - stringlength... I think this should count the number of characters in a string, not the binary length. It would be nice if this function (strlen) would be transparent with mb things too, as no code needs to be changed then. Compatibility is king. strlen() returns the number of bytes, has been for at least 5 years. You just can't change that because the name is slightly better or slightly worse. Simply stating Compability is king. doesn't do it for. And just saying that it has been like that for at least 5 years doesn't mean it can not change. It won't break BC at all (not even for the mbstring users, as the mb_strlen() overloads the 'normal' strlen(). Heck, it will even break BC for those users! Also, from the docs (and that is all what should matter to users): strlen (PHP 3, PHP 4 ) strlen -- Get string length Where can I find that it returns the number of bytes? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
On Tue, 3 Sep 2002, Zeev Suraski wrote: I'm going to argue about it (fiercely :) if/when it becomes more relevant, but not a microsecond sooner... we'll meet again in battle then :) Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?
On Tue, Sep 03, 2002 at 11:21:12AM +0300, Andrey Hristov wrote: So the docs are right? Note that keys are preserved. array_unique() sorts the values treated as string at first, then will keep the first key encountered for every value, and ignore all following keys. It does not mean that the key of the first related value from the unsorted array will be kept. They are right for current releases, but what is not said is that it's not obvious what the order will be after sorting, so it's not really useful to know that the first key for every value is kept. I would say that the order now is undefined. I think it will be better with the new code when there is a defined and concistent ordering, and I would say it's backwards compatible since previously it wasn't defined. As Melvyn just said in another post, mergesort would be nice since it's stable, so I would like to see zend_mergesort() perhaps. It can be better than qsort on small datasets, and some qsort() implementations use it when the partition size is small enough. Some platforms have mergesort() or msort(). In one way it might make sense to use the systems native sorting functions when available, they are probably faster. OTOH it might lead to different sorting on different platforms which is why I say that which key for a value array_unique() keeps is undefined (except for new implementation). I would expect mergesort functions to always be stable though, so it might be safe to use native implementations. Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?
- Original Message - From: Stig Venaas [EMAIL PROTECTED] To: Andrey Hristov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 03, 2002 11:43 AM Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken? They are right for current releases, but what is not said is that it's not obvious what the order will be after sorting, so it's not really useful to know that the first key for every value is kept. I would say that the order now is undefined. I think it will be better with the new code when there is a defined and concistent ordering, and I would say it's backwards compatible since previously it wasn't defined. In one way it might make sense to use the systems native sorting functions when available, they are probably faster. OTOH it might lead to different sorting on different platforms which is why I say that which key for a value array_unique() keeps is undefined (except for new implementation). I would expect mergesort functions to always be stable though, so it might be safe to use native implementations. IMO that's good idea to have keys ordered too. All my nightmares with array_diff() came from that the key order is undefined and I tried all kind of tricks (traversing like in a marathon forward and backwards to find are there couples [k,v] that are identical). Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?
On Tue, Sep 03, 2002 at 11:47:58AM +0300, Andrey Hristov wrote: IMO that's good idea to have keys ordered too. All my nightmares with array_diff() came from that the key order is undefined and I tried all kind of tricks (traversing like in a marathon forward and backwards to find are there couples [k,v] that are identical). Note that the sorting in array_unique() is just for internal reasons, it did until recently determine which key was returned for a value though. I think for array_diff() and array_intersect() the ordering should be as in the first argument, current implementations do that. I don't think any sorting should be done except internally and that is just to make things efficient. If we need something like array_diff_associative() etc those should also do sorting internally for efficiency (I see no other way), and not rely on the unsorted output from array_diff() etc. Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
Wez Furlong wrote: Having been using it to handle more than 105,000 email messages over the last 18 months *in production*, I have to disagree. *SNIP* Now, the mbstr-enc-trans might have had some stability issues, but as I've been saying, it is NOT enabled by default, and lets print a warning about it when it is turned on. mbstr-enc-trans is introduced when Rui merged mbstring(jstring) to php4 source tree. It was added since php3-i18n had this capability built in. Rui removed mbstr-enc-trans option so that it's ready to be a default module. We can control encoding translation by mbstring.encoding_translation = On|Off now. (the name may be better to be renamed to input_encoding_translation or input_translation. Opinions?) AFAIK, there is no serious bug in mbstring. If there is serious problem, let us know so that it can be addressed. Speaking of API, current API will not be changed. The API is there since php3 days. This is another reason why mbstring is considered stable. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
Zeev Suraski wrote: At 10:25 03/09/2002, [EMAIL PROTECTED] wrote: strlen() overloaded by mb_strlen might causes some problems because it is used to measure length of string and to measure length of binary data. So, a new function to measure string length only (or binary length only) will be necessary. Sure, I don't think that will be a problem. I do. strlen() should go on returning the binary length, breaking that is really a bad idea. We can introduce a new function altogether that returns the 'calculated' MB aware length, that won't cause any problems. We are planning to introduce string_len() that always returns number of chars and byte_len()(or string_byte()) that returns number of bytes. (There mbstring has mb_strlen() so string_len() would be alias) Current strlen() do not provide these features. byte_len()'s problem is there are too many functions that allocates more memory than it is needed. We might have to do something about this or just return length inculdes garbages or make it act like current strlen() Opinions? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken?
- Original Message - From: Stig Venaas [EMAIL PROTECTED] To: Andrey Hristov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, September 03, 2002 11:53 AM Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] array_unique broken? On Tue, Sep 03, 2002 at 11:47:58AM +0300, Andrey Hristov wrote: IMO that's good idea to have keys ordered too. All my nightmares with array_diff() came from that the key order is undefined and I tried all kind of tricks (traversing like in a marathon forward and backwards to find are there couples [k,v] that are identical). Note that the sorting in array_unique() is just for internal reasons, it did until recently determine which key was returned for a value though. I think for array_diff() and array_intersect() the ordering should be as in the first argument, current implementations do that. I don't think any sorting should be done except internally and that is just to make things efficient. If we need something like array_diff_associative() etc those should also do sorting internally for efficiency (I see no other way), and not rely on the unsorted output from array_diff() etc. Stig Yup, I am talking about sorting for internal reasons. array_diff_assoc(iative)() will share most of the code with array_diff() if there is a routine that guaratees that after sorting the keys in equal value blocks will be also sorted. Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
AFAIK, there is no serious bug in mbstring. If there is serious problem, let us know so that it can be addressed. Then start with removing double url decoding of the input... and then fix the mad separator counter ... Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.h Zend zend.h
Sebastian Bergmann wrote:
sebastian Tue Sep 3 05:41:41 2002 EDT
Modified files:
/Zend zend.h
/ZendEngine2zend.h
Log:
Add html_errors to zend_utility_values.
Patch by Jan Lehnardt [EMAIL PROTECTED].
Someone please review/commit the rest of the patch.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Index: Zend/zend_ini.c
===
RCS file: /repository/Zend/zend_ini.c,v
retrieving revision 1.18
diff -u -r1.18 zend_ini.c
--- Zend/zend_ini.c 6 Jan 2002 15:21:09 - 1.18
+++ Zend/zend_ini.c 2 Sep 2002 19:59:12 -
@@ -308,15 +308,25 @@
display_string = ini_entry-orig_value;
display_string_length = ini_entry-orig_value_length;
} else {
- display_string = ino value/i;
- display_string_length = sizeof(ino value/i)-1;
+ if(zend_uv.html_errors) {
+ display_string = ino value/i;
+ display_string_length = sizeof(ino
+value/i)-1;
+ } else {
+ display_string = no value;
+ display_string_length = sizeof(no value)-1;
+ }
}
} else if (ini_entry-value ini_entry-value[0]) {
display_string = ini_entry-value;
display_string_length = ini_entry-value_length;
} else {
- display_string = ino value/i;
- display_string_length = sizeof(ino value/i)-1;
+ if(zend_uv.html_errors) {
+ display_string = ino value/i;
+ display_string_length = sizeof(ino value/i)-1;
+ } else {
+ display_string = no value;
+ display_string_length = sizeof(no value)-1;
+ }
}
ZEND_WRITE(display_string, display_string_length);
}
@@ -354,9 +364,17 @@
value = NULL;
}
if (value) {
- zend_printf(font color=\%s\%s/font, value, value);
+ if (zend_uv.html_errors) {
+ zend_printf(font color=\%s\%s/font, value, value);
+ } else {
+ ZEND_PUTS(value);
+ }
} else {
- ZEND_PUTS(ino value/i;);
+ if (zend_uv.html_errors) {
+ ZEND_PUTS(ino value/i;);
+ } else {
+ ZEND_PUTS(no value);
+ }
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.h Zend zend.h
I am, I have to make some changes to it first...
At 12:51 03/09/2002, Sebastian Bergmann wrote:
Sebastian Bergmann wrote:
sebastian Tue Sep 3 05:41:41 2002 EDT
Modified files:
/Zend zend.h
/ZendEngine2zend.h
Log:
Add html_errors to zend_utility_values.
Patch by Jan Lehnardt [EMAIL PROTECTED].
Someone please review/commit the rest of the patch.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Content-Type: text/plain; charset=us-ascii name=patch
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=patch
Index: Zend/zend_ini.c
===
RCS file: /repository/Zend/zend_ini.c,v
retrieving revision 1.18
diff -u -r1.18 zend_ini.c
--- Zend/zend_ini.c 6 Jan 2002 15:21:09 - 1.18
+++ Zend/zend_ini.c 2 Sep 2002 19:59:12 -
@@ -308,15 +308,25 @@
display_string = ini_entry-orig_value;
display_string_length =
ini_entry-orig_value_length;
} else {
- display_string = ino value/i;
- display_string_length = sizeof(ino
value/i)-1;
+ if(zend_uv.html_errors) {
+ display_string = ino value/i;
+ display_string_length =
sizeof(ino value/i)-1;
+ } else {
+ display_string = no value;
+ display_string_length = sizeof(no
value)-1;
+ }
}
} else if (ini_entry-value ini_entry-value[0]) {
display_string = ini_entry-value;
display_string_length = ini_entry-value_length;
} else {
- display_string = ino value/i;
- display_string_length = sizeof(ino value/i)-1;
+ if(zend_uv.html_errors) {
+ display_string = ino value/i;
+ display_string_length = sizeof(ino
value/i)-1;
+ } else {
+ display_string = no value;
+ display_string_length = sizeof(no value)-1;
+ }
}
ZEND_WRITE(display_string, display_string_length);
}
@@ -354,9 +364,17 @@
value = NULL;
}
if (value) {
- zend_printf(font color=\%s\%s/font, value, value);
+ if (zend_uv.html_errors) {
+ zend_printf(font color=\%s\%s/font, value,
value);
+ } else {
+ ZEND_PUTS(value);
+ }
} else {
- ZEND_PUTS(ino value/i;);
+ if (zend_uv.html_errors) {
+ ZEND_PUTS(ino value/i;);
+ } else {
+ ZEND_PUTS(no value);
+ }
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.h Zendzend.h
On Tue, 3 Sep 2002, Zeev Suraski wrote:
I am, I have to make some changes to it first...
oops, sorry for that commit, I'll revert
Derick
At 12:51 03/09/2002, Sebastian Bergmann wrote:
Sebastian Bergmann wrote:
sebastian Tue Sep 3 05:41:41 2002 EDT
Modified files:
/Zend zend.h
/ZendEngine2zend.h
Log:
Add html_errors to zend_utility_values.
Patch by Jan Lehnardt [EMAIL PROTECTED].
Someone please review/commit the rest of the patch.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Content-Type: text/plain; charset=us-ascii name=patch
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=patch
Index: Zend/zend_ini.c
===
RCS file: /repository/Zend/zend_ini.c,v
retrieving revision 1.18
diff -u -r1.18 zend_ini.c
--- Zend/zend_ini.c 6 Jan 2002 15:21:09 - 1.18
+++ Zend/zend_ini.c 2 Sep 2002 19:59:12 -
@@ -308,15 +308,25 @@
display_string = ini_entry-orig_value;
display_string_length =
ini_entry-orig_value_length;
} else {
- display_string = ino value/i;
- display_string_length = sizeof(ino
value/i)-1;
+ if(zend_uv.html_errors) {
+ display_string = ino value/i;
+ display_string_length =
sizeof(ino value/i)-1;
+ } else {
+ display_string = no value;
+ display_string_length = sizeof(no
value)-1;
+ }
}
} else if (ini_entry-value ini_entry-value[0]) {
display_string = ini_entry-value;
display_string_length = ini_entry-value_length;
} else {
- display_string = ino value/i;
- display_string_length = sizeof(ino value/i)-1;
+ if(zend_uv.html_errors) {
+ display_string = ino value/i;
+ display_string_length = sizeof(ino
value/i)-1;
+ } else {
+ display_string = no value;
+ display_string_length = sizeof(no value)-1;
+ }
}
ZEND_WRITE(display_string, display_string_length);
}
@@ -354,9 +364,17 @@
value = NULL;
}
if (value) {
- zend_printf(font color=\%s\%s/font, value, value);
+ if (zend_uv.html_errors) {
+ zend_printf(font color=\%s\%s/font, value,
value);
+ } else {
+ ZEND_PUTS(value);
+ }
} else {
- ZEND_PUTS(ino value/i;);
+ if (zend_uv.html_errors) {
+ ZEND_PUTS(ino value/i;);
+ } else {
+ ZEND_PUTS(no value);
+ }
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
---
Did I help you? http://www.derickrethans.nl/link.php?url=giftlist
Frequent ranting: http://www.derickrethans.nl/
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Unresolved external symbol: _zend_uv
php_cli.obj: error LNK2001: Unresolved external symbol: _zend_uv -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
At 00:15 03.09.2002, Edin Kadribasic wrote: i still don't see why we shouldn't just disable everything by default and write a 'default configure' script... I don't see why you're so upset that some extensions are enabled by default. The main rule so far was if the extension is stable and if it does not depend on external libraries it was enabled. This was done so people who get PHP through hosted services have the most PHP functionality available to them. This IMHO outweighs the slight inconvenience of adding a few configure options for people who compile PHP themselves. Edin I can only agree to that! I do not see some extra bytes for the binaries being a problem with to days disk and memory sizes. For me it seems VERY important to have a great API/functionality in PHP. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0) / LICENSE
Joao Prado Maia wrote: Can someone shed some light into this issue ? Could you please stop discussion on the *CVS* list? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pread solutions needed
Please read bug: http://bugs.php.net/bug.php?id=15983 As it states, currently non-i386 Linux boxen are having difficulty with the session functionality. Mainly because of the pread/pwrite functions. The check passes, and the HAVE_PREAD/HAVE_PWRITE flags are given. One of the users has discovered that this is actually a bug in the glibc implementations on non-i386 machines. There is a message (linked in the bug report) that states this has been fixed in CVS as of Tues, 30th July 2002. So what does the official PHP stance become? Do we want to put a series of #defines around this code section to make sure Linux/non-i386 doesn't use this code? Or do we just ignore it and wait for the new glibc code to filter down? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pread solutions needed
Why do we use pread in the first place? Zeev At 21:27 03/09/2002, Dan Kalowsky wrote: Please read bug: http://bugs.php.net/bug.php?id=15983 As it states, currently non-i386 Linux boxen are having difficulty with the session functionality. Mainly because of the pread/pwrite functions. The check passes, and the HAVE_PREAD/HAVE_PWRITE flags are given. One of the users has discovered that this is actually a bug in the glibc implementations on non-i386 machines. There is a message (linked in the bug report) that states this has been fixed in CVS as of Tues, 30th July 2002. So what does the official PHP stance become? Do we want to put a series of #defines around this code section to make sure Linux/non-i386 doesn't use this code? Or do we just ignore it and wait for the new glibc code to filter down? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~dank a little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pread solutions needed
On Tue, 3 Sep 2002, Zeev Suraski wrote: Why do we use pread in the first place? I don't know. It looks like we have options for both pread and non-pread capable systems (ext/session/mod_files.c:270). I personally don't see any specific reason to use the HAVE_PREAD version, if we have something that works universally. At 21:27 03/09/2002, Dan Kalowsky wrote: Please read bug: http://bugs.php.net/bug.php?id=15983 As it states, currently non-i386 Linux boxen are having difficulty with the session functionality. Mainly because of the pread/pwrite functions. The check passes, and the HAVE_PREAD/HAVE_PWRITE flags are given. One of the users has discovered that this is actually a bug in the glibc implementations on non-i386 machines. There is a message (linked in the bug report) that states this has been fixed in CVS as of Tues, 30th July 2002. So what does the official PHP stance become? Do we want to put a series of #defines around this code section to make sure Linux/non-i386 doesn't use this code? Or do we just ignore it and wait for the new glibc code to filter down? --- Dan KalowskyA little less conversation, http://www.deadmime.org/~dank a little more action. [EMAIL PROTECTED] - A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default extensions (was: mbstring)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 03 September 2002 08:31 am, Marcus Börger wrote: At 00:15 03.09.2002, Edin Kadribasic wrote: i still don't see why we shouldn't just disable everything by default and write a 'default configure' script... I don't see why you're so upset that some extensions are enabled by default. The main rule so far was if the extension is stable and if it does not depend on external libraries it was enabled. This was done so people who get PHP through hosted services have the most PHP functionality available to them. This IMHO outweighs the slight inconvenience of adding a few configure options for people who compile PHP themselves. Edin I can only agree to that! I do not see some extra bytes for the binaries being a problem with to days disk and memory sizes. For me it seems VERY important to have a great API/functionality in PHP. I agree 100%. Some hosts will not enable anything more than the defaults and forget about asking them to.takes too much time. - -- ~Paul Nicholson It said uses Windows 98 or better, so I loaded Linux! Registered Linux User #183202 using Register Linux System # 81891 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9dQ+YDyXNIUN3+UQRAsaPAKCeiGdfgJlZM4HosVRmksOndzYBAQCfdPde sLQ7iTJaUnHnvFTf3/G7gmQ= =7oIi -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] translate capitalized functions in create_stubs
Hi When we use prototype files for ext_skel, we noticed that a function name with capital letters doesn't work properly since php extension must have lowercase function names. However, ext_skel doesn't warn or fix an erroneous prototype file. Here's a small patch to the create_stubs file which will both warn users that a function name from the prototype file contains capital letters, and it will lowercase the function name. Out of curiosity, why ext_skel/create_stubs a shell/awk script? Were it written in perl, Windows users could use it too. Is there a design reason for shell/awk or is it just historical? dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] translate capitalized functions in create_stubs
inlining patch since my attachment seemed to fail...
dave
===
--- create_stubs.ORIG Tue Sep 3 13:21:41 2002
+++ create_stubsTue Sep 3 13:33:01 2002
@@ -153,6 +153,13 @@
spec_str = spec_str \
+## php extension must use lower case function names.
+## this will translate any capitalized letter to lowercase
+## and warn the user
+ if (match(func_name,[A-Z]) != 0) {
+ printf(NOTICE: lower casing function name '%s'\n,func_name)
+ func_name = tolower(func_name)
+ }
funcs[num_funcs] = func_name
types[num_funcs] = func_type
maxargs[num_funcs] = args_max
-Original Message-
From: David Viner [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 03, 2002 1:43 PM
To: Php-Dev@lists. php. net
Subject: [PHP-DEV] [PATCH] translate capitalized functions in
create_stubs
Hi
When we use prototype files for ext_skel, we noticed that a function name
with capital letters doesn't work properly since php extension must have
lowercase function names. However, ext_skel doesn't warn or fix an
erroneous prototype file. Here's a small patch to the create_stubs file
which will both warn users that a function name from the prototype file
contains capital letters, and it will lowercase the function name.
Out of curiosity, why ext_skel/create_stubs a shell/awk script? Were it
written in perl, Windows users could use it too. Is there a design reason
for shell/awk or is it just historical?
dave
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] translate capitalized functions in create_stubs
I have committed your patch. As for the Windows issue. It works pretty well under a regular cygwin setup, which is required for building PHP anyway, so I don't think there is much of a problem here. -Rasmus On Tue, 3 Sep 2002, David Viner wrote: Hi When we use prototype files for ext_skel, we noticed that a function name with capital letters doesn't work properly since php extension must have lowercase function names. However, ext_skel doesn't warn or fix an erroneous prototype file. Here's a small patch to the create_stubs file which will both warn users that a function name from the prototype file contains capital letters, and it will lowercase the function name. Out of curiosity, why ext_skel/create_stubs a shell/awk script? Were it written in perl, Windows users could use it too. Is there a design reason for shell/awk or is it just historical? dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GD broken ? compiler errors !
Is GD extension fundamentally broken as of 4.2.2 ? Configuration: PHP version 4.2.2, OS: HPUX, compiler : gcc 2.9 library versions noted in configure line below.. GD extension fails to build as a self-contained extension, with compiler errors during make. Here is a snapshot # cd ext/gd # ../../pear/scripts/phpize # export PHP_ZLIB_DIR=/path/zlib-1.1.4 # ./configure --with-gd=/path/gd-1.8.4 \ --with-jpeg-dir=/path/jpeg-6b \ --with-png-dir=/path/libpng-1.0.11 \ --with-xpm-dir=/path/xpm-3.4k \ --with-freetype-dir=/path/freetype-2.1.2 \ --with-t1lib=/path/t1lib-1.3.1 \ --with-php-config=/path/php-4.2.2/pear/scripts/php-config \ --prefix=/path # make gd.c:97: conflicting types for `gdIOCtx' /path/gd-1.8.4/gd_io.h:18: previous declaration of `gdIOCtx' gd.c: In function `zif_imageloadfont': gd.c:486: `php_stream' undeclared (first use in this function) gd.c:486: (Each undeclared identifier is reported only once gd.c:486: for each function it appears in.) gd.c:486: `stream' undeclared (first use in this function) gd.c:494: `REPORT_ERRORS' undeclared (first use in this function) ... more errors Examining the first error i found that gdIOCtx has a simple declaration of type FILE in ext/gd/gd.c. But a header that is part of the gd library v1.8.4 (gd_io.h) has a conflicting ( and more sophisticated .. struct ) declaration for the same. But then looks like there are more errors besides that one. I tried picking up the GD related files (except config.m4) that have changed in recent 2/3 weeks from cvs.php.net but it didnt help. adding.. #define HAVE_PHP_STREAM in gd.c seemed to fix the compiler error on undeclared first use of php_stream Definitions for macros ... REPORT_ERRORS , PHP_STREAM_IS_STDIO , PHP_STREAM_CAST_TRY_HARD seems to be missing. -- Roshan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Clone function of ftp_quit
PHP_FALIAS(ftp_quit, ftp_close, NULL) BC. Why not renaming it to ftp_close so it can be like fclose, mysql_close... that would be more generic than quit. Objections? Ideas? -- Merci de nous avoir choisi. - Thanks you for your choice. Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] [EMAIL PROTECTED] www.GroupAKT.com - Hébergement Group. www.WorldAKT.com - Hébergement de sites Internet -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Attila Strauss [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring
[Sorry if this is a little late: my ISP has also had some mail problems over the last 48 or so hours, so I've had a random quantity of mail delivered in a random sequence over that period, most of it coming through today :-/] On 09/02/02, [EMAIL PROTECTED] wrote: On Mon, 2 Sep 2002, Wez Furlong wrote: On 09/01/02, [EMAIL PROTECTED] wrote: No, not really. It was noted by more than one person that it breaks some simple things in PHP, affecting the bahavior of scripts that are already out there. Umm, how many of those me too's have actually tried using PHP with mbstring? I did use it. I don't doubt that you did :-) I was referring to the majority of me too's that were citing the wrong reasons and who obviously had not tried it (or even read the PR that sparked this thread). I just don't want stuff to get backed-out with an apparent majority vote when the majority are actually voting based on some incorrect assumptions! Anyway, things seem to have been resolved and people are happier now with Rui's patch (based on the mail that I *have* seen today!). --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] --disable-all / --enable-all
Attached patch adds --disable-all / --enable-all configure options to disable/enable all extensions You can do something like this now (tested): ./configure --disable-all --with-zlib To only include zlib extension. Or the other way around (untested): ./configure --enable-all --without-zlib And of course (totally untested..): ./configure --enable-all=shared,/usr/local This only affects those extensions which use the PHP_ARG_* macros. The patch adds one extra parameter to them to tell which options are 'extension' options. Any option which should not be enabled automatically should have it set to 'no'. (default for it is 'yes') Please test this. I don't want to commit it before I hear some positive comments.. phpize'd builds should be tested also. (I did try that, and it works.. :) --Jani disable_all.patch.gz Description: GNU Zip compressed data -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: --disable-all / --enable-all
Nice work. -- Nicos - CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com - Hébergement de sites Internet Jani Taskinen [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Attached patch adds --disable-all / --enable-all configure options to disable/enable all extensions You can do something like this now (tested): ./configure --disable-all --with-zlib To only include zlib extension. Or the other way around (untested): ./configure --enable-all --without-zlib And of course (totally untested..): ./configure --enable-all=shared,/usr/local This only affects those extensions which use the PHP_ARG_* macros. The patch adds one extra parameter to them to tell which options are 'extension' options. Any option which should not be enabled automatically should have it set to 'no'. (default for it is 'yes') Please test this. I don't want to commit it before I hear some positive comments.. phpize'd builds should be tested also. (I did try that, and it works.. :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] var_export() and arrays
?php
$array = array('foo', 'bar');
var_export($array);
?
prints
array (
0 = 'foo',
1 = 'bar',
)
The comma after 'bar' is superfluous.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] var_export() and arrays
On Wed, 4 Sep 2002, Sebastian Bergmann wrote:
?php
$array = array('foo', 'bar');
var_export($array);
?
prints
array (
0 = 'foo',
1 = 'bar',
)
The comma after 'bar' is superfluous.
It is, but removeing it would require quite a hack. I thought of fixing
that, but as Zend doesn't have problems with it, I decided that it
doesn't matter if there is a comma or not.
Derick
---
Did I help you? http://www.derickrethans.nl/link.php?url=giftlist
Frequent ranting: http://www.derickrethans.nl/
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZendEngine2 availability
Hi guys, Sorry if this is out of place, but is there any estimates as to when the famous Z2 might be ready? I am starting out a large OO project in PHP, and I would really like - love - to use some of the new features. Otherwise, is there somewhere I can get latest builds? Any indications are appreciated! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
