[PHP-DEV] Re: Reverting ext/mbstring patch
Hi, The obvious problem looked like handling of internal encoding. When the script is written in an encoding that is incompatible with the lexer, the script is converted into internal encoding (input_filter) for parsing, and then gets every string literal converted back to the original encoding (output_filter). Some of the test cases fail because the internal encoding is not set to an encoding that is bidirectionally convertible from/to the script encoding (ISO-8859-1 against Shift_JIS for example.) I'm gonna make a fix to change that behavior so that the input_filter always converts the script into UTF-8 instead of internal_encoding. Also gonna take a closer look into your patch. You basically don't have to adjust the style of codes under libmbfl as it is a separate library. Bugfixes are always appreciated. Regards, Moriyoshi On Thu, Mar 3, 2011 at 4:44 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Moriyoshi, OK, I thought the email was lost, so ignore the email I just resent. In general I like your patch and I would glad to see it fixed. I already tried to make some fixes. See the attached patch. Thanks. Dmitry. On 03/02/2011 11:51 PM, Moriyoshi Koizumi wrote: Hey, I think I can fix it somehow. Please don't be haste with it. I am going to look into it. Moriyoshi On Tue, Mar 1, 2011 at 11:35 PM, Dmitry Stogovdmi...@zend.com wrote: Hi, I'm going to revert Moriyoshi patch from December and some following fixes. I like the idea of the patch, but it just doesn't work as expected. It breaks 10 tests, but in general it breaks most things related to Unicode (declare statement, multibyte scripts, exif support for Unicode, multibyte POST requests). I tried to fix it myself, but I just can't understand how it should work (it's too big). It also has several places where integers messed with pointers, old API messed with new one and so on. I'm going to revert (apply the attached patch) on Thursday. Following is the list of failed tests: Shift_JIS request [tests/basic/029.phpt] Testing declare statement with several type values [Zend/tests/declare_001.phpt] Zend Multibyte and ShiftJIS [Zend/tests/multibyte/multibyte_encoding_001.phpt] Zend Multibyte and UTF-8 BOM [Zend/tests/multibyte/multibyte_encoding_002.phpt] Zend Multibyte and UTF-16 BOM [Zend/tests/multibyte/multibyte_encoding_003.phpt] encoding conversion from script encoding into internal encoding [Zend/tests/multibyte/multibyte_encoding_005.phpt] 086: bracketed namespace with encoding [Zend/tests/ns_086.phpt] Check for exif_read_data, Unicode user comment [ext/exif/tests/exif003.phpt] Check for exif_read_data, Unicode WinXP tags [ext/exif/tests/exif004.phpt] Test mb_get_info() function [ext/mbstring/tests/mb_get_info.phpt] Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
Moriyoshi Koizumi wrote: Regarding the patch (https://gist.github.com/835698): I don't see a switch to disable the internal parse on configure. I don't see any obvious reason it should be able to be turned off through the build option. The only problem is binary size increase, which I guess is quite subtle. Seems sufficiently different from normal cli. The patch looks messy as it splits main in two functions, so it gets hard to follow, but is probably good overall. Assuming you are mentioning about the option parsing portion of the code, yes, it's a bit messy, but I had to do so because runtime initialization procedure is very different from the ordinary CLI. Wasn't critizising you. It's a limitation of unified diffs, which can't say move this bunch of code 25 lines down. A bit hard to follow, but aparently good. The change from php_printf to printf in line 3988 looks wrong. php_printf() eventually redirects the output to sapi_module.ub_write(), which should only be available after proper SAPI initialization. The changed part can be reached before the initialization and it absolutely makes no sense to use php_printf() when you simply want to print a message text before the script starts in the console. Fair enough. Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? cli-win32 version of PHP doesn't have an associated console and is supposed to use to create applications without console interactions (i.e. GUI). So, It doesn't make sense to enable this feature for it. With the embedded web server, the interaction would be done via the browser. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
Hi, On Thu, Mar 3, 2011 at 3:35 PM, Alexey Zakhlestin indey...@gmail.com wrote: On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi m...@mozo.jp wrote: Hi, Just to let you know that I wrote a RFC about built-in web server feature with which PHP can serve contents without a help of web servers. That would be handy for development purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Interesting, indeed. I noticed, that you hardcode mimetypes and index_files. Mimetypes can probably be obtained from the system — we even had some extension doing that. And index_files should be configurable, because there are some situations when people don't want any mime-types at all. Also, it would be good to be able to configure which files are actually parsed by php, not just served. Currently, these are only .php files We coundn't always count on the existence of mime.types, which is likely installed with Apache that is uncalled for. Neither do I see any good reason to make index files configurable because I have hardly seen such a peculiar setting for several years that uses file names other than index.html or index.php for index files. I used to use index.htm for technical reasons though. In short, if you need to configure it more, it'd be better off installing Apache to do the right job. I would like to cover just a marginal part of the developer needs with this. Regards, Moriyoshi -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
Hi, 2011/3/3 Ángel González keis...@gmail.com: Moriyoshi Koizumi wrote: Regarding the patch (https://gist.github.com/835698): I don't see a switch to disable the internal parse on configure. I don't see any obvious reason it should be able to be turned off through the build option. The only problem is binary size increase, which I guess is quite subtle. Seems sufficiently different from normal cli. I've seen a number of people arguing on the same, but I'd rather have them both in for the sake of simplicity. As discussed when the CLI version of PHP was born, multiple PHP binaries actually have confused the users to a certain degree. The patch looks messy as it splits main in two functions, so it gets hard to follow, but is probably good overall. Assuming you are mentioning about the option parsing portion of the code, yes, it's a bit messy, but I had to do so because runtime initialization procedure is very different from the ordinary CLI. Wasn't critizising you. It's a limitation of unified diffs, which can't say move this bunch of code 25 lines down. A bit hard to follow, but aparently good. I would have put a whitespace-ignoring diff as well ;-) Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? cli-win32 version of PHP doesn't have an associated console and is supposed to use to create applications without console interactions (i.e. GUI). So, It doesn't make sense to enable this feature for it. With the embedded web server, the interaction would be done via the browser. It is not intended to be daemonized at all since it's just a development web server. To do more, Apache should work great then. Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On Thu, 3 Mar 2011, Moriyoshi Koizumi wrote: In short, if you need to configure it more, it'd be better off installing Apache to do the right job. I would like to cover just a marginal part of the developer needs with this. I like it being small and simple as well. Sometimes forcing people to use one method actually makes things easier to use. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
Derick Rethans wrote: In short, if you need to configure it more, it'd be better off installing Apache to do the right job. I would like to cover just a marginal part of the developer needs with this. I like it being small and simple as well. Sometimes forcing people to use one method actually makes things easier to use. AND a lot easier to debug when people are having problems getting something working ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.6RC2 Released for Testing
The second release candidates of 5.3.6 was just released for testing and can be downloaded here: http://downloads.php.net/johannes/php-5.3.6RC2.tar.bz2 (md5sum: f870685b8715600e056d2dbb22920576) http://downloads.php.net/johannes/php-5.3.6RC2.tar.gz (md5sum: 32e88f8a2dd1e756d386b7fe625c7e8b) The windows binaries are available at: http://windows.php.net/qa/ Windows users please mind that we don't provide VS6 builds anymore. This is a step in the release process of this versions and goal is having a final version by next week. Majority of the changes are of the bug fix variety. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. Johannes Schlüter PHP 5.3 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Class Access Modifiers
Has there been any discussion on access modifiers for classes? I looked through the existing RFCs and searched through old discussions on the mailing list but didn't come up with anything. Specifically, I think it would be beneficial (for framework developers in particular) if classes could be marked as public, private, etc. I haven't really thought through exact definitions on how each modifier would restrict but here is a use case. A developer is working on an object-oriented framework that uses namespaces and uses classes extensively. He considers many of the classes to be for internal use only, that is, they will only be used by the internal workings of the framework core, not by any web application that somebody builds using his framework. That being the case, the developer would like to restrict access to certain classes so that they can only be accessed in certain situations. Proposal (after five minutes of thought) 1. Public - A class can be instantiated or called statically from anywhere. For reasons of backward compatibility a class without any modifier would be considered public. 2. Internal - A class can only be instantiated/called from within the same root namespace. If I have a class Core\Mvc\View, only from within a class sharing the same root namespace (ex: Core\Html\Textbox) would I be able to access the View class. 3. Private - A class can only be instantiated/called from within the exact same namespace. Example, class Core\Mvc\View could only be accessed from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). What do people think? I'm not too concerned with the exact three I listed above, but more and more I think it would be wise if there were a way to restrict the accessibility of classes between namespaces. Jarrod Nettles Application Developer - Technology INCCRRA p 309.829.5327 - f 309.828.1808 This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission. Please consider your environmental responsibility before printing this e-mail
Re: [PHP-DEV] Class Access Modifiers
I'm writing a RFC about improvements on the current OO Model. do you want to add this? http://wiki.php.net/rfc/object-model-improvements Martin Scotta On Thu, Mar 3, 2011 at 2:21 PM, Jarrod Nettles jnett...@inccrra.org wrote: Has there been any discussion on access modifiers for classes? I looked through the existing RFCs and searched through old discussions on the mailing list but didn't come up with anything. Specifically, I think it would be beneficial (for framework developers in particular) if classes could be marked as public, private, etc. I haven't really thought through exact definitions on how each modifier would restrict but here is a use case. A developer is working on an object-oriented framework that uses namespaces and uses classes extensively. He considers many of the classes to be for internal use only, that is, they will only be used by the internal workings of the framework core, not by any web application that somebody builds using his framework. That being the case, the developer would like to restrict access to certain classes so that they can only be accessed in certain situations. Proposal (after five minutes of thought) 1. Public - A class can be instantiated or called statically from anywhere. For reasons of backward compatibility a class without any modifier would be considered public. 2. Internal - A class can only be instantiated/called from within the same root namespace. If I have a class Core\Mvc\View, only from within a class sharing the same root namespace (ex: Core\Html\Textbox) would I be able to access the View class. 3. Private - A class can only be instantiated/called from within the exact same namespace. Example, class Core\Mvc\View could only be accessed from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). What do people think? I'm not too concerned with the exact three I listed above, but more and more I think it would be wise if there were a way to restrict the accessibility of classes between namespaces. Jarrod Nettles Application Developer - Technology INCCRRA p 309.829.5327 - f 309.828.1808 This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission. Please consider your environmental responsibility before printing this e-mail
Re: [PHP-DEV] Volnitsky substring search algo
Damien Tournoud damz at damz.org writes: On Sun, Feb 27, 2011 at 12:50 PM, Jordi Boggiano j.boggiano at seld.be wrote: The algorithm seems flawed to me, at least in its reference implementation. There does not seem to be any guarantee that the returned position is really the *first* occurrence of the needle in the haystack. This is a bug. This algorithm is still something very new. The implementation could be fixed (by adding an explicit string matching when building the hash table, and by storing *all* the occurrences of a given W in SS), but that will increase the overall cost (both computing and memory) of the algorithm. Bug was fixed by reversing hash fill order (without increase of overall cost). @ All About the licence. I am not a layer, I need to figure out the licensing. I intend to give PHP project a special license, I just need to clarify several things. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] streams problem in 5.3
Hi! I try to do some complex code with custom streams and I have discovered the following problem: The code in main/streams/cast.c, specifically _php_stream_cast, creates fopencookie() synthetic stream for streams that are not actual file streams. Which works fine until such stream is used in include(), in which case it ultimately arrives at zend_stream_fixup(). Which would in turn call zend_stream_fsize() - which would do fstat(fileno(file_handle-handle.fp), buf) - and that would fail since you can't get fileno for FILE* created by fopencookie. Which ultimately means I can't use my custom streams for include(), which is bad. Now, looking at the code, it doesn't actually need the exact size - http streams can be included just fine - but insists on having it if it has fp (which it can have for basically any kind of stream due to the cookie trick). Does anyone has any idea why and if it can be fixed? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On 03/02/2011 12:55 PM, Moriyoshi Koizumi wrote: Hi, Just to let you know that I wrote a RFC about built-in web server feature with which PHP can serve contents without a help of web servers. That would be handy for development purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Regards, Moriyoshi To allow for future changes, all options should require flags. For example, php -S localhost:8000 -d docroot instead of the currently proposed php -S localhost:8000 docroot Have you thought about integration with run-tests.php? -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On Fri, Mar 4, 2011 at 11:17 AM, Christopher Jones christopher.jo...@oracle.com wrote: On 03/02/2011 12:55 PM, Moriyoshi Koizumi wrote: Hi, Just to let you know that I wrote a RFC about built-in web server feature with which PHP can serve contents without a help of web servers. That would be handy for development purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Regards, Moriyoshi To allow for future changes, all options should require flags. For example, php -S localhost:8000 -d docroot instead of the currently proposed php -S localhost:8000 docroot That might make sense. I am thinking that being unable to specify a document root with a router script is a bit inconsistent. Have you thought about integration with run-tests.php? Not in mind yet, but if it's better than CGI. Moriyoshi -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
