RE: [PHP-DEV] DateTime improvement
What about putting the new DateTimeImmutable (or whatever it will be called) into a PHP namespace? Something like \PHP\Foobar\DateTimeImmutable Is it generally planned to use namespaces for PHP classes? In my opinion it would be nice if the SPL and other classes would be put into such a namespace, too. Are there any plans to do that? Christian Stoller -Original Message- From: Peter Cowburn [mailto:petercowb...@gmail.com] Sent: Friday, December 21, 2012 1:14 AM To: Lazare Inepologlou Cc: Larry Garfield; internals@lists.php.net Subject: Re: [PHP-DEV] DateTime improvement On 20 December 2012 20:06, Lazare Inepologlou linep...@gmail.com wrote: Of course, I have no idea if anyone in userspace is using DateTimeImmutable... Well, it seems unlikely, unless he is Yoda or French. I mean, in English, it is common to put the adjective in front of the noun, isn't it? Class names aren't particularly subject, too strictly, to English grammar rules. Besides, the coding standards [1] dictate the class name should be prefixed with the 'parent set' (e.g. extension name), which in this case is not Immutable. [1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152 Lazare INEPOLOGLOU Ingénieur Logiciel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
Hi, On 21.12.2012 8:15, Patrick Schaaf wrote: APC takes a LOCK_EX in exactly one place, apc_bin_dumpfile(), which does not look to me like it's related to include. The usage there is fishy anyway, not exactly sure, but I think the open that happens before taking LOCK_EX, will have truncated the file already, leading to the same type of problem as discussed above wrt concurrent readers. Usage is fishy, but it's small and can reproduce the error. Don't really know what code hits that in my production environment or is it even the same problem but it seems to have similar backtrace. So, my conclusion would be that it is the code snippet above, and not any part of PHP or the kernel, that is at fault. Oh? Did I understand you correctly? If you can code PHP that crashes PHP, it's that codes fault not PHP's fault? I've always thought PHP to be high level programming language where PHP handles things for you and you can't code anything that crashes it like that with bus error? I think that it should at least gracefully exit, log error, what caused what and where. Better option would be that it just works. And if you don't see anything to be done in PHP, I think then at least documentation of include/require should have big warning explaining that PHP doesn't guarantee include/require not to crash PHP itself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)
I don't have much time to work on this now. More next year ! Have ahappy Xmas. On 12/20/2012 09:43 PM, Levi Morrison wrote: As mentioned earlier, I've been working on a library(https://github.com/morrisonlevi/Ardent) with an honest effort to make the data-structures usable in several different programming styles. I've tried several designs, but requiring something to implement a `Comparable` interface turned out to not be a very good way to do things, for several reasons I don't feel like going into at the moment. - I hope you'll take a look at the current Map(https://github.com/morrisonlevi/Ardent/blob/master/src/Ardent/Map.php) and Set(https://github.com/morrisonlevi/Ardent/blob/master/src/Ardent/Set.php) interfaces in my library and see if there is anything you are missing. I'd really love it if you cloned the repository and tried using it in your project. I'm always looking for feedback.
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
Hi! Oh? Did I understand you correctly? If you can code PHP that crashes PHP, it's that codes fault not PHP's fault? I've always thought PHP to be high level programming language where PHP handles things for you and you can't code anything that crashes it like that with bus error? There are a number of ways that you could lead to a crash in PHP. Say, some infinite loops can end up in crashes. Calling some functions with specific parameters on some systems could end up in crashes. Some libraries in some versions can lead to crashes. Etc, etc. We live in imperfect world, and that includes software which necessarily relies on other software. Making it perfectly 100% crash proof would be impractical. If you have any proposal on how to solve this particular problem, you are welcome to propose a patch. Otherwise, much more practical solution would be to fix that code. I think that it should at least gracefully exit, log error, what caused what and where. Better option would be that it just works. We can't really gracefully exit when OS produces bus error on missing part of the file, because you changed it non-atomically. The only way to avoid it would be to not use mmap, which would be a performance hit and also not very helpful as you'd just get a mangled file instead. -- 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] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
On Thursday 20 December 2012 23:23:43 Stas Malyshev wrote: Hi! Is include supposed to take a LOCK_EX somehow? I can neither see that in php- src (5.4.9) nor APC-trunk, doing a cursory grepping. I'm not sure how any lock would help, since locks are optional, meaning you still can do the same thing without the locks. I'm well aware of the advisory nature of file locks. include taking a LOCK_EX could have helped - when any .tpl file modifying code also does LOCK_EX. I do NOT want to propose include doing that! It's just that the original poster or whoever created that piece of code with LOCK_EX in the file_put_contents(), apparently thought it might work out that way. tmpfiles and rename are definitely the correct way to handle that. best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
On Friday 21 December 2012 10:41:59 Jani Ollikainen wrote: So, my conclusion would be that it is the code snippet above, and not any part of PHP or the kernel, that is at fault. Oh? Did I understand you correctly? If you can code PHP that crashes PHP, it's that codes fault not PHP's fault? I've always thought PHP to be high level programming language where PHP handles things for you and you can't code anything that crashes it like that with bus error? I understand your sentiment. To follow up the sentiment in code, there would be two options: 1) capture SIGBUS (and SIGSEGV probably, depending on platform), and in the signal handler, to lots of funny dances to guess from the stack what kind of error message would be helpful to the end user or end developer. 2) remove any attempt to use mmap to speed up reading, generally, or as an ini option. I would personally expect mmap-reading not to make a huge difference in performance anyway, as the short segment double buffering that it avoids, will probably be swamped by any kind of parsing of the content anyway. But probably when people went to the lengths of implementing mmap based reading in the PHP core, they had some good reasons to do so... I think that it should at least gracefully exit, log error, what caused what and where. Better option would be that it just works. It CANNOT just work. It wouldn't work reliably without any use of mmap, either. Concurrently modifying and reading one and the same file, will always run into consistency problems, and doing that is CERTAINLY the fault of the code that does it. best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5.5.0alpha2 release
On Fri, Dec 21, 2012 at 1:51 AM, Adam Harvey ahar...@php.net wrote: On 21 December 2012 01:26, jpauli jpa...@php.net wrote: We just tagged PHP 5.5.0alpha2 today. This release contains bug fixes against alpha1, as well as new features. Are we going to have a news post for this on the Web site? (Alternative question: would you like me to write one?) Yep, writing it for today :-) Julien
Re: [PHP-DEV] DateTime improvement
On Thu, 20 Dec 2012, Larry Garfield wrote: I've seen DateTimeValue used elsewhere for userspace immutable date time objects. Whether that indicates we SHOULD or SHOULD NOT use that for an in-C version, I don't know. (I'm inclined to say should-but-namespace, but I don't know if we're doing that yet.) http://php.net/manual/en/userlandnaming.rules.php cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
Hi,
On 21.12.2012 11:24, Patrick Schaaf wrote:
I understand your sentiment.
And I try to understand your technical point of view. I've thought
that PHP handles concurrent stuff so that those kind of things
won't happen and the user won't need to have for example mutexes
to do stuff.
But I think I've been wrong and for performance sake there isn't
stuff like that.
I understood you correctly using temp file and then rename should fix
that? Like this?
?php
if ($argv[1] 0) {
while ($argv[1]--)
{
file_put_contents('test.tpl.tmp', ?php #.str_repeat('A',
mt_rand(4000, 5000)). ?\n, LOCK_EX);
rename('test.tpl.tmp','test.tpl');
}
} else {
$p2 = popen(php test3.php 100, r);
while (1) include 'test.tpl';
}
?
Tested that quickly and cannot get it to do bus error.
Or how should you then do that stupid example so that it won't
crash? It might maybe help me, to find something in my production
code to fix and get rid of the problem.
But I think that include/require should have warning box saying
something about including/requiring files that you might overwrite
in other instance as I can't be only one expecting PHP to handle
these kind of situations.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
I don't think it would be ok to move just DateTimeImmutable to the namespace. There were proposal to move all the php functions and classes in namespaces, so that for example str_replace() could be \Str\replace() and array_map() could be \Array\map() and so on. On Fri, 21 Dec 2012 12:33:04 +0400, Christian Stoller stol...@leonex.de wrote: What about putting the new DateTimeImmutable (or whatever it will be called) into a PHP namespace? Something like \PHP\Foobar\DateTimeImmutable Is it generally planned to use namespaces for PHP classes? In my opinion it would be nice if the SPL and other classes would be put into such a namespace, too. Are there any plans to do that? Christian Stoller -Original Message- From: Peter Cowburn [mailto:petercowb...@gmail.com] Sent: Friday, December 21, 2012 1:14 AM To: Lazare Inepologlou Cc: Larry Garfield; internals@lists.php.net Subject: Re: [PHP-DEV] DateTime improvement On 20 December 2012 20:06, Lazare Inepologlou linep...@gmail.com wrote: Of course, I have no idea if anyone in userspace is using DateTimeImmutable... Well, it seems unlikely, unless he is Yoda or French. I mean, in English, it is common to put the adjective in front of the noun, isn't it? Class names aren't particularly subject, too strictly, to English grammar rules. Besides, the coding standards [1] dictate the class name should be prefixed with the 'parent set' (e.g. extension name), which in this case is not Immutable. [1] https://github.com/php/php-src/blob/master/CODING_STANDARDS#L152 Lazare INEPOLOGLOU Ingénieur Logiciel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
I understood you correctly using temp file and then rename should fix
that? Like this?
file_put_contents('test.tpl.tmp', ?php #.str_repeat('A',
mt_rand(4000, 5000)). ?\n, LOCK_EX);
rename('test.tpl.tmp','test.tpl');
Exactly!
You could also do it like this:
$tmpname = 'test.tpl.tmp.'.posix_getpid();
file_put_contents($tmpname, '');
rename($tmpname, 'test.tpl');
That way - adding the process ID to the temporary filename - does not run into
the danger of two processes changing the file at the same time. The LOCK_EX
should handle that case, too, but I usually go for the appended PID approach
and don't worry about file locking at all.
best regards
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete traits redesign for 5.5
Hi, This is more or less final proposed patch for 5.4 http://pastebin.com/ceiWWD4N It fixes implementation mistakes and makes the whole implementation much simpler. I hope I didn't introduce new bugs :) Of course I checked it with PHP test suite, but it would be great to test it with real life applications that use traits. The patch keeps binary compatibility, and changes only error messages and behavior in error situations. It must not affect any applications. I like to commit the patch in 5.4 and above on next week. I would simplify the trait implementation much more, but the conflict resolution rules allows to make so many tricks that all needs to be checked :( Anyway, I'll think about it a bit more. Any feedback is welcome. Thanks. Dmitry. On Tue, Dec 18, 2012 at 3:46 PM, Stefan Marr p...@stefan-marr.de wrote: Hi Dmitry: On 18 Dec 2012, at 12:37, Dmitry Stogov wrote: I'm going to take a deep look into trait implementation and provide a better solution for 5.5. The current implementation is really wired and makes a lot of troubles for maintenance and each new fix, makes new troubles :( Sorry, that's mostly me lacking understanding of the PHP internals. And there are many wired corner cases that have to be covered. I'm going to work on it with top priority during last few days and then send a patch. Thanks for looking into it. I'll be able to test things over christmas. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Re: [PHP-DEV] Adding Generator::throw()
On Mon, Dec 17, 2012 at 11:45 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Dec 17, 2012 at 11:03 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Basically the method allows you to do delegate error handling to the
coroutine, rather than doing it yourself (as you are not always able to
do
it). It is particularly useful in more complicated settings, e.g. if you
are doing task scheduling through coroutines. For a small sample of how
Could you expand on this point a bit more? It sounds like using
exceptions for flow control, which is usually a very bad idea.
this looks like see http://taskjs.org/. What the -throw() method
would do
in these examples is that it allows to check for errors by try/catching
the
yield statement (rather than going for some odd solution with error
callbacks).
Could you point to some specific example?
The basic idea behind this kind of task management is that you can do
asynchronous operations just like you would synchronous ones, i.e. without
the need for callbacks or wait-loops. Whenever the functions wants to
perform some async action it doesn't directly do it, rather it yields the
operation that does it. The scheduler then waits until that operation is
finished (running other tasks in the meantime) and only resumes the
coroutine once it is finished. This way you can write async code without
the ugliness that is usually involved with async code.
Here is an example to get a rough idea of how the use looks like:
function server() {
// ...
$stuff = yield $socket-recv();
// ...
yield $socket-send($response);
// ...
}
The throw() method comes in when you want to handle errors on those
asynchronous operations. Without it you would be forced to use error codes.
throw() allows you to do the error handling just like you would normally
do. E.g. consider that $socket-send() were a fallible operation. Then you
could catch errors like this:
function server() {
// ...
try {
yield $socket-send($response);
} catch (SocketException $e) {
// do some error handling
}
// ...
}
In this case the outside code (where the exception comes from) can't know
what it should do in case of an error. Only the code in the coroutine knows
that. That's why you need some possibility to throw the error into the
context that knows how to deal with it.
I hope that this makes it a bit more clear.
Nikita
If there are no further objections I'll commit this tomorrow.
Nikita
Re: [PHP-DEV] Adding Generator::throw()
On 12/21/2012 06:54 AM, Nikita Popov wrote: If there are no further objections I'll commit this tomorrow. Nikita This feature needs documenting in Generator RFC before it is committed. The RFC will be referenced by people new to the feature and so it should have a complete list of changes. Thanks, Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Changes in libcurl for CURLOPT_SSL_VERIFYHOST in 7.28.1
The following solution was implemented : https://github.com/php/php-src/commit/517f800277a11d6ce05b0e1afcd0e76dc544d452 Pierrick On 18 December 2012 23:35, Pierrick Charron pierr...@webstart.fr wrote: Hi all, About 2 month ago, we had a discussion on this list about the fact that CURLOPT_SSL_VERIFYHOST was most of the time used with a Boolean value (true) instead of int values (0,1 or 2). This bad usage was leading to some security issues. The result of this discussion was to trigger a notice if someone tried to set the CURLOPT_SSL_VERIFYHOST to true (boolean), and was committed to = 5.4 On November 20th, Daniel (the author of libcurl) released cURL 7.28.1 which no longer support the 1 value for CURLOPT_SSL_VERIFYHOST. This change introduced some bugs as #63795 (you'll find the cause of the bug in the comments). To fix this bug, and to minimize as much as possible the impact of this change, I'm proposing to do the following changes in the libcurl extension for future releases : When using libcurl 7.28.1, if someone try to set CURLOPT_SSL_VERIFYHOST to 1 (or true), set the value to 1, but trigger a notice to inform that this value is deprecated. When using libcurl = 7.28.1 if someone try to set CURLOPT_SSL_VERIFYHOST to 1 (or true), set CURLOPT_SSL_VERIFYHOST to 2, trigger a notice to inform the user that this value is no longer supported as of libcurl 7.28.1 but keep returning true. Also, as stated by Remy in bug #63795, when PHP is built with curl-wrappers, the context option curl_verify_ssl_host sets CURLOPT_SSL_VERIFYHOST to 1. I would like to modify this code to set CURLOPT_SSL_VERIFYHOST to 2. Since curl-wrappers is still marked as experimental I don't think this will cause a lot of troubles. If you have any comment, please do, otherwise, I'll commit those changes on Friday to all branches (including 5.3). Thanks Pierrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
