Re: [PHP-DEV] PHP 4.4.9RC1
On Tue, Jul 22, 2008 at 3:57 PM, Derick Rethans [EMAIL PROTECTED] wrote: Hello! I packed PHP 4.4.1RC9 today, which you can find here: http://downloads.php.net/derick/ 4.4.9RC1? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.4.9RC1
On Fri, 25 Jul 2008, Xuefer wrote: On Tue, Jul 22, 2008 at 3:57 PM, Derick Rethans [EMAIL PROTECTED] wrote: I packed PHP 4.4.1RC9 today, which you can find here: http://downloads.php.net/derick/ 4.4.9RC1? Uhm yes. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list isn't better to migrate to git or mercurial ? http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git it's faster and better on my opinion (why wasting time to convert later from svn to git ) [EMAIL PROTECTED] for anyone who wants to help with the move. If you're familiar with what I've already done so far (http://wiki.php.net/svnmigration) and want to help, I beg you on my knees to subscribe (send a mail to [EMAIL PROTECTED]) and let us know what you want to do :). It's past time for PHP to make this step a just a little bit further into the future and I hope we can work together to make it happen. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- developer flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Does anyone have a copy of APC.dll that is newer than the one from January for NTS Windows?
Does anyone have a copy of APC.dll that is newer than the one from January for not-thread-safe Windows? Would be much obliged, thank you! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
marius popa wrote: On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list isn't better to migrate to git or mercurial ? http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git it's faster and better on my opinion (why wasting time to convert later from svn to git ) We have 1000+ people with commit access, many of whom are not very technical. We need something with mature Windows tools for those folks and something that isn't completely different to their way of working. The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. We don't need to be on the bleeding edge of revision control systems. In fact, I prefer to very much be a very very slow follower in that particular area to make sure that all tools are extremely mature by the time we go anywhere near them. The last thing we want to do is slow down PHP development any further by forcing people to fight with a bleeding edge set of tools. When a winner eventually emerges in the de-centralized revision control world and everyone creates tools for all the various platforms, we'll have a look, but I predict that to be years away. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 09:48, Rasmus Lerdorf wrote: marius popa wrote: On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list isn't better to migrate to git or mercurial ? http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to- git it's faster and better on my opinion (why wasting time to convert later from svn to git ) We have 1000+ people with commit access, many of whom are not very technical. We need something with mature Windows tools for those folks and something that isn't completely different to their way of working. The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Lukas Kahwe Smith wrote: The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. What do you mean by that? hgsvn and git-svn don't need any server-side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 10:11, Rasmus Lerdorf wrote: Lukas Kahwe Smith wrote: The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. What do you mean by that? hgsvn and git-svn don't need any server- side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. I mean that if several people work on a changeset, that they still might want to have a join central repo. Of course dvcs allows direct exchange of patches as well, but it might still be a good idea to have this central dvcs repo for historical reasons (lets say some stuff is attempted, it is then abandonded and then picked up by someone else). Also in terms of standardization I mean that even core developers can get overwhelmed if they end up having to use git here, and hg there. Then again we are still far away from having that many different subprojects that need dvcs. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. Maybe it's just about having the possibilities for developers to share experimental trees on a php.net side so that people from outside can pull from it easily and not to remember a bunch of urls to get the trees of some developers working on interesting patchsets. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 10:25, Lars Strojny wrote: Hi Rasmus, Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf: [...] What do you mean by that? hgsvn and git-svn don't need any server- side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. git-svn is really slow when you check out a huge repository. And PHP- SRC will be huge. So it might be worth to export nightly git repos and to provide a space for developers to create personal repositories from that nightly repos for collaboration (think re2c, PDO_MYSQLND, etc. pp.) BTW: I talked to some mercurial developers at a recent google code event here in Zurich. They said that their svn bridging is still not at the same level as that of git, but its being actively addressed. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hi, David Soria Parra wrote: However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. Maybe it's just about having the possibilities for developers to share experimental trees on a php.net side so that people from outside can pull from it easily and not to remember a bunch of urls to get the trees of some developers working on interesting patchsets. launchpad allows you to create mirror Bazaar repos. The original can be svn or bazaar. This is how a bzr repo from Launchpad is provided, although the main repo is svn. Launchpad registration is free and easy. Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hello Lukas, Friday, July 25, 2008, 10:26:59 AM, you wrote: On 25.07.2008, at 10:25, Lars Strojny wrote: Hi Rasmus, Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf: [...] What do you mean by that? hgsvn and git-svn don't need any server- side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. git-svn is really slow when you check out a huge repository. And PHP- SRC will be huge. So it might be worth to export nightly git repos and to provide a space for developers to create personal repositories from that nightly repos for collaboration (think re2c, PDO_MYSQLND, etc. pp.) BTW: I talked to some mercurial developers at a recent google code event here in Zurich. They said that their svn bridging is still not at the same level as that of git, but its being actively addressed. I don't care for slow or fast. Becuase only about 10 people out of a 1000 or so will use any bridge to anywhere. We need to keep our fast development for php-src, pecl, pear and docs running while improving our development process at the same time. So far we didn't upgrade anywhere because non of the tools did offer any real advantage for us - PHP. Subversion is the only one that is not 10 or a 100 times more complex. In fact for 99% of our repository users the change will limit to a one time checkout where a dirrerent repository name, uri or whatever they will name it is being used and when having to type svn instead of cvs. And as always one should address the 99% and not the 1%. At leat I for one would prefer not to loose too many contributers along the way. Either way with subversion 1.5 we get not only general svn support for transactions and moving but also merge tracking. Personally the killer feature here is transactions. And I don't think I have to explain why. But whatever, no other tool is able to provide what we want while being mature and working on all platforms at the same timr. This thread again shows the PHP development. A few people wanting to help and endless amounts of people needing to mail anything they ever thought of. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 11:46, Marcus Boerger wrote: I mean that if several people work on a changeset, that they still might want to have a join central repo. Of course dvcs allows direct exchange of patches as well, but it might still be a good idea to have this central dvcs repo for historical reasons (lets say some stuff is attempted, it is then abandonded and then picked up by someone else). Also in terms of standardization I mean that even core developers can get overwhelmed if they end up having to use git here, and hg there. Then again we are still far away from having that many different subprojects that need dvcs. I still cannot follow you. Do you even know about these tools? I have not used any of them enough in practice to really know them well. If two parties use git or hg they are all fine. And everyone else is fine too because they don' t have to learn dcms (btw, it's a distributed cms as in code/configuraqtion management system: http://en.wikipedia.org/wiki/Code_management_system). Anyway you don't want to teach for example our documentation group to use git or hg. Besides the fact thaqt there is no windows support for git they do not have the slightest use whatsoever for local branching. Though of course anyone who is can safely start it's own perfectly working local one. The point is: - re2c experimental work used git - mysqlnd used bzr If I am developer X and for some reason I wanted to be involved in the re2c and the mysqlnd stuff, then I would need to know both (or atleast have a stable and easy to use bridge between the two). This is why I am suggesting to standardize on a dvcs. Also as others have made it more clear than I did in my initial post. A central place for people to merge their pages upstream makes it easier for people to join/examine the development (even if the original people have abonded the effort), without having to hunt down people to get their changesets. It might also be a convenient way to prepare before the final push into our central repo. So again it would be useful to have some default space for teams to place the stable state of their collaboration. Finally Lars also mentioned that it might be a good idea to keep a mirror of svn because creating a copy of current svn in some dvcs is not going to be instant. this again suggests it would make sense for us to standardize on a specific dvcs or we have to start offering mirrors for all candidates. Hope I am not too far off-base with these observations .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Thu, 2008-07-24 at 20:25 -0400, Gwynne Raskind wrote: Yes, I read that. But the conversion of the repository itself is only half the battle. There are a bunch of scripts in CVSROOT that need to be ported over to SVN somehow. My plan was to work on those next. not only CVSROOT, there are also some vcs-specific script in php-src (like cvsclean or scripts for snaps building), scripts on the snaps box to build snaps, on master to generate docs and websites, which all have to found, analyzed, rewritten. So a rather long running project where he repository conversion is one of the smallest problem (enough big projects did that so if there are problems there are many places to ask, whereas the whole infrastructure around has to be analyzed...) :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, 2008-07-25 at 10:26 +0200, David Soria Parra wrote: However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. Maybe it's just about having the possibilities for developers to share experimental trees on a php.net side so that people from outside can pull from it easily and not to remember a bunch of urls to get the trees of some developers working on interesting patchsets. Sharing trees can also be done with svn. A repository structure might look something like that: root + active master tees | + trunk | + php 5.3 | \ ... + developer trees | + johannes | | \ my private play ground | \ \ archive + php 5.2 + php 5.1 \ svn 1.5 should allow merging between these tree's, but all such things should be discussed on the other, new list :-) johannes P.S. I'm a git fan boy but see good reasons against it for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, Jul 25, 2008 at 04:06, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. Has the phpdoc revision/translation problem been looked into/fixed? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
Did you yet? :) Am 24.07.2008 um 14:42 schrieb Michael Wallner: David Zülke wrote: So... who's gonna commit it? :) I'll commit in the next few hours if nobody objects. Mike -- 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] CVS to SVN Migration
On 25 Jul 2008, at 10:58, Lukas Kahwe Smith wrote: On 25.07.2008, at 11:46, Marcus Boerger wrote: I mean that if several people work on a changeset, that they still might want to have a join central repo. Of course dvcs allows direct exchange of patches as well, but it might still be a good idea to have this central dvcs repo for historical reasons (lets say some stuff is attempted, it is then abandonded and then picked up by someone else). Also in terms of standardization I mean that even core developers can get overwhelmed if they end up having to use git here, and hg there. Then again we are still far away from having that many different subprojects that need dvcs. I still cannot follow you. Do you even know about these tools? I have not used any of them enough in practice to really know them well. If two parties use git or hg they are all fine. And everyone else is fine too because they don' t have to learn dcms (btw, it's a distributed cms as in code/configuraqtion management system: http://en.wikipedia.org/wiki/Code_management_system). Anyway you don't want to teach for example our documentation group to use git or hg. Besides the fact thaqt there is no windows support for git they do not have the slightest use whatsoever for local branching. Though of course anyone who is can safely start it's own perfectly working local one. The point is: - re2c experimental work used git We used svn, we converted the 5.3 branch to svn and then did an export at the end and merged back to CVS. - mysqlnd used bzr If I am developer X and for some reason I wanted to be involved in the re2c and the mysqlnd stuff, then I would need to know both (or atleast have a stable and easy to use bridge between the two). This is why I am suggesting to standardize on a dvcs. Also as others have made it more clear than I did in my initial post. A central place for people to merge their pages upstream makes it easier for people to join/examine the development (even if the original people have abonded the effort), without having to hunt down people to get their changesets. It might also be a convenient way to prepare before the final push into our central repo. So again it would be useful to have some default space for teams to place the stable state of their collaboration. Finally Lars also mentioned that it might be a good idea to keep a mirror of svn because creating a copy of current svn in some dvcs is not going to be instant. this again suggests it would make sense for us to standardize on a specific dvcs or we have to start offering mirrors for all candidates. With the svn hooks you can keep a mirror of CVS running and make t read only apart from commits to the svn repository. Those using cvsread would then not notice much difference. Hope I am not too far off-base with these observations .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Jul 25, 2008, at 6:34 AM, Hannes Magnusson wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. Has the phpdoc revision/translation problem been looked into/fixed? No, not yet, but it will have to be. I intend for discussion on svn- [EMAIL PROTECTED] For the record, I will more or less ignore discussion that happens on internals@ on the subject; the idea of making a new list was to keep noise about the situation out of the ears of people who don't care. Especially with the 5.3 release coming, the last thing we need is extra noise without any means of categorizing. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
On 25.07.2008, at 12:34, David Zülke wrote: Did you yet? :) yes .. it has been commited. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On 25.07.2008, at 12:41, Scott MacVicar wrote: On 25 Jul 2008, at 10:58, Lukas Kahwe Smith wrote: On 25.07.2008, at 11:46, Marcus Boerger wrote: I mean that if several people work on a changeset, that they still might want to have a join central repo. Of course dvcs allows direct exchange of patches as well, but it might still be a good idea to have this central dvcs repo for historical reasons (lets say some stuff is attempted, it is then abandonded and then picked up by someone else). Also in terms of standardization I mean that even core developers can get overwhelmed if they end up having to use git here, and hg there. Then again we are still far away from having that many different subprojects that need dvcs. I still cannot follow you. Do you even know about these tools? I have not used any of them enough in practice to really know them well. If two parties use git or hg they are all fine. And everyone else is fine too because they don' t have to learn dcms (btw, it's a distributed cms as in code/configuraqtion management system: http://en.wikipedia.org/wiki/Code_management_system). Anyway you don't want to teach for example our documentation group to use git or hg. Besides the fact thaqt there is no windows support for git they do not have the slightest use whatsoever for local branching. Though of course anyone who is can safely start it's own perfectly working local one. The point is: - re2c experimental work used git We used svn, we converted the 5.3 branch to svn and then did an export at the end and merged back to CVS. Ah ok .. the point was just to provide an example that if its a free for all on what dvcs to use, it can make things harder for people that join/examine different experimental branches :) regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
On Wed, Jul 23, 2008 at 19:40, Noah Fontes [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Zülke wrote: Yeah. We discussed that quite a while back when I sent over the ignore_errors options patch-like thing in November: http://thread.gmane.org/gmane.comp.php.devel/46003 I think we should do it. But what about other 3xx redirect codes? How are those handled? I think PHP implicitly follows any Location headers it can. That's probably not the right behavior, but for an automated process it's not bad. I think that 3xx status codes, if they appear without a Location header, should also probably not throw errors. They could provide valuable information about the status of a page (particularly 304 Not Modified), so I've updated the patch: http://cynigram.com/~nfontes/http_fopen_wrapper.patch BTW, any chance this could be rolled into 5.3? I think the BC break is pretty non-notable, and it would be nice to stop throwing errors for successful responses. I think changing all 3xx status codes to be success is a slightly more bc break then you think. A simple example: I do a file_get_contents() request. Store it in a local buffer. I do a second file_get_contents(), get a error (304) back, print out my buffer. Now, in 5.3.0 the 304 is treated as success so I naturally discard my buffer and print the results of the new request... Whooopsy, there was no data :( -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
On Thu, 24 Jul 2008, Jack Steadman wrote: Thank you for taking the time to explain this to me. A couple more points below: strtotime() has always accepted month and day numbers 0 in order to express last month of the previos year and last day of the previous month. Take: So my biggest issue with this is that it's exception-case behavior, treating truly invalid dates as valid dates for no obvious reason. Who needs this functionality? Why is it even a good idea? It's nice to find the last day of next month. A close second is that this behavior is completely undocumented. http://us.php.net/strtotime states that the time argument to strtotime is The string to parse, according to the GNU Date Input Formats syntax and that false is returned on failure. GNU date formats do NOT allow for zero months and days (see http://www.gnu.org/software/tar/manual/html_node/Calendar-date-items.htm l#SEC116). No official mention is made of the exception case that you describe. The closest the docs come is a user comment on the strtotime page from June 19 of this year (perhaps someone who upgraded to 5.2.6 and found this behavior for the first time?) warning other users that 2008-00-14 is interpreted as 2007-12-14. Yes, the documentation is broken. I'm working on fixing that. This is not actually the case. Take one of our machines (first part of php -i included here): snip This 64-bit machine is running 5.2.5 and returns false on the all-zero datetime string. It was upgraded last week to 5.2.6 and started returning the large negative integer. snip *Something* changed in date handling between 5.2.5 and 5.2.6. Whether you perpetuate the exception case or not, it *is* a regression. Yes, because there was a regression in 5.2.[45]: php-5.2.6$ sapi/cli/php -n -r 'var_dump( strtotime( -00-00 00:00 ) );' int(-62169987600) php-5.2.5$ sapi/cli/php -n -r 'var_dump( strtotime( -00-00 00:00 ) );' bool(false) php-5.2.4$ sapi/cli/php -n -r 'var_dump( strtotime( -00-00 00:00 ) );' bool(false) even in PHP 5.1 it doesn't return false (although it's incorrect): $ php-5.1dev -n -r 'var_dump( strtotime( -00-00 00:00 ) );' int(943916400) and *even* on 4.3.9: $ php-4.3.9 -n -r 'var_dump( strtotime( -00-00 00:00 ) );' int(943916400) regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] __toBoolean()
First, apologies if this has been discussed before. I couldn't find
any evidence to suggest that it has, but it kind of surprises me.
As strings aren't objects in PHP, __toString is quite a useful
construct, but it begs the question as to why there aren't
__toprimitve-type for each of the primitive types in PHP? Through
SPL, we have __toArray covered, and I presume that there is no real
value in a __toInteger or __toFloat, but __toBoolean seems as it could
be quite useful, since it would allow an object to be evaluated in a
conditional. Eg. a simple use-case:
class Validation {
protected $errors = array();
function fail($error) {
$this-errors[] = $error;
}
function __toBoolean() {
return count($this-errors) === 0;
}
}
I wonder if the reason why this haven't been suggest yet is because of:
a) Nobody thought about it before
b) Somebody thought about it, and figured out that it was a bad idea
While this looks pretty simple, I have a hunch that introducing such
behaviour could have far-fetching consequences, as it hooks into PHP's
dynamic typing system. It also have a smell of C++'s ability to
overload operators and the ensuing shooting of feet. On the other
hand, it does allow some nifty tricks, and as it's optional,
presumably people would only use it when it actually makes sense.
Even if this, for some reason, doesn't fit into core PHP, it might be
a candidate for SPL? (Even if the syntax would then be slightly
different)
Have a nice weekend.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hi, http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch The last CVS commit for apply_func_t and TSRMLS_CC conflicted with the patches, I merged the conflicting line manually and reuploaded the patches to the same location. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
Hi Dmitry,
I saw that you commited this patch, with the addition of only replacing
persistent constants (just mentioning for others on the list). The attached
patches have a few tweaks:
The main thing I noticed is that if something creates a persistent,
case-INsensitive constant (any of those in standard PHP, besides
TRUE/FALSE/NULL?), it could still wrongly be substituted. My change
eliminates that possibility.
Checking Z_TYPE(c-value) != IS_CONSTANT[_ARRAY] isn't needed with the
persistent check now, is it?
From orginal patch (zend_constants.c part), the memcmp(...) != 0 isn't
needed as it will always be true. If it wasn't, the *first* hash lookup
wouldn't have failed. :-) Like I said in the original message, it's old
code from a long time ago, but was never removed...
- Matt
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
I would propose the attached patch for this optimization.
Opcode caches and encoders will have to disable this optimization with
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION
Any objections?
Thanks. Dmitry.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.74
diff -u -p -d -r1.647.2.27.2.41.2.74 zend_compile.c
--- Zend/zend_compile.c 24 Jul 2008 11:47:49 - 1.647.2.27.2.41.2.74
+++ Zend/zend_compile.c 24 Jul 2008 14:40:12 -
@@ -3804,6 +3804,12 @@ static zend_constant* zend_get_ct_const(
if (c-flags CONST_CT_SUBST) {
return c;
}
+ if (!CG(current_namespace)
+ !(CG(compiler_options) ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION)
+ Z_TYPE(c-value) != IS_CONSTANT
+ Z_TYPE(c-value) != IS_CONSTANT_ARRAY) {
+ return c;
+ }
return NULL;
}
/* }}} */
@@ -5169,12 +5175,14 @@ void zend_do_use(znode *ns_name, znode *
void zend_do_declare_constant(znode *name, znode *value TSRMLS_DC) /*
{{{ */
{
zend_op *opline;
+ zend_constant *c;
if(Z_TYPE(value-u.constant) == IS_CONSTANT_ARRAY) {
zend_error(E_COMPILE_ERROR, Arrays are not allowed as constants);
}
- if (zend_get_ct_const(name-u.constant TSRMLS_CC)) {
+ c = zend_get_ct_const(name-u.constant TSRMLS_CC);
+ if (c (c-flags CONST_CT_SUBST)) {
zend_error(E_COMPILE_ERROR, Cannot redeclare constant '%s',
Z_STRVAL(name-u.constant));
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.27
diff -u -p -d -r1.316.2.8.2.12.2.27 zend_compile.h
--- Zend/zend_compile.h 24 Jul 2008 11:47:49 - 1.316.2.8.2.12.2.27
+++ Zend/zend_compile.h 24 Jul 2008 14:40:13 -
@@ -762,6 +762,9 @@ END_EXTERN_C()
/* generate ZEND_DECLARE_INHERITED_CLASS_DELAYED opcode to delay early
binding */
#define ZEND_COMPILE_DELAYED_BINDING (14)
+/* disable constant substitution at compile-time */
+#define ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION (15)
+
/* The default value for CG(compiler_options) */
#define ZEND_COMPILE_DEFAULT ZEND_COMPILE_HANDLE_OP_ARRAY
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.832
diff -u -r1.832 zend_compile.c
--- Zend/zend_compile.c 25 Jul 2008 04:54:56 - 1.832
+++ Zend/zend_compile.c 25 Jul 2008 09:30:00 -
@@ -3996,24 +3996,20 @@
zstr lookup_name = zend_u_str_case_fold(Z_TYPE_P(const_name),
Z_UNIVAL_P(const_name), Z_UNILEN_P(const_name), 1, lookup_name_len);
if (zend_u_hash_find(EG(zend_constants), Z_TYPE_P(const_name),
lookup_name, lookup_name_len+1, (void **) c)==SUCCESS) {
- if ((c-flags CONST_CS) memcmp(c-name.v,
Z_UNIVAL_P(const_name).v,
UG(unicode)?UBYTES(Z_USTRLEN_P(const_name)):Z_STRLEN_P(const_name))!=0) {
+ if ((c-flags CONST_CT_SUBST) !(c-flags
CONST_CS)) {
efree(lookup_name.v);
- return NULL;
+ return c;
}
- } else {
- efree(lookup_name.v);
- return NULL;
}
efree(lookup_name.v);
+ return NULL;
}
if (c-flags CONST_CT_SUBST) {
return c;
}
if ((c-flags CONST_PERSISTENT)
!CG(current_namespace)
- !(CG(compiler_options) ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION)
- Z_TYPE(c-value) != IS_CONSTANT
- Z_TYPE(c-value) != IS_CONSTANT_ARRAY) {
+ !(CG(compiler_options) ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION)) {
return c;
}
return NULL;
Index: Zend/zend_constants.c
RE: [PHP-DEV] CVS to SVN Migration
Hi Lukas, We have already had several cases in the past where developers have collaborated on a CVS branch. The main reason why this hasn't been common practice is because CVS branching sucks and because some developers didn't feel comfortable with using branches regardless of the tool. I think SVN goes quite far in making development in branches more productive. I therefore see no reason why mysqlnd and re2c collaborators could not just use an SVN branch. There is and has never been a rule not to use branches in the main PHP repository for such collaborations. My 2 Rappen :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hello Lukas, Friday, July 25, 2008, 11:58:42 AM, you wrote: On 25.07.2008, at 11:46, Marcus Boerger wrote: I mean that if several people work on a changeset, that they still might want to have a join central repo. Of course dvcs allows direct exchange of patches as well, but it might still be a good idea to have this central dvcs repo for historical reasons (lets say some stuff is attempted, it is then abandonded and then picked up by someone else). Also in terms of standardization I mean that even core developers can get overwhelmed if they end up having to use git here, and hg there. Then again we are still far away from having that many different subprojects that need dvcs. I still cannot follow you. Do you even know about these tools? I have not used any of them enough in practice to really know them well. If two parties use git or hg they are all fine. And everyone else is fine too because they don' t have to learn dcms (btw, it's a distributed cms as in code/configuraqtion management system: http://en.wikipedia.org/wiki/Code_management_system). Anyway you don't want to teach for example our documentation group to use git or hg. Besides the fact thaqt there is no windows support for git they do not have the slightest use whatsoever for local branching. Though of course anyone who is can safely start it's own perfectly working local one. The point is: - re2c experimental work used git no we usde svn - mysqlnd used bzr I can still contribute to mysql stuff as all that matters is the main repository. If a smaller team forms and decides on bzr or git or hg then they still have to synch with the main repository, be it cvs or svn. We did the same with our re2c development. The advantage of svn over cvs is that we get integration/migration support with the new tools. If I am developer X and for some reason I wanted to be involved in the re2c and the mysqlnd stuff, then I would need to know both (or atleast have a stable and easy to use bridge between the two). This is why I am suggesting to standardize on a dvcs. There is no need to do so. Also as others have made it more clear than I did in my initial post. A central place for people to merge their pages upstream makes it easier for people to join/examine the development (even if the original people have abonded the effort), without having to hunt down people to get their changesets. It might also be a convenient way to prepare before the final push into our central repo. So again it would be useful to have some default space for teams to place the stable state of their collaboration. Finally Lars also mentioned that it might be a good idea to keep a mirror of svn because creating a copy of current svn in some dvcs is not going to be instant. this again suggests it would make sense for us to standardize on a specific dvcs or we have to start offering mirrors for all candidates. Hope I am not too far off-base with these observations .. A cvs read-only mirror would be nice to allow the old way of checking out stuff. But there I fail to see the reason to limit our selves to one additional other tool, nor do I see a reason to complicate matters even more by giving people other repositories that we somehow merge or not. SVN works everywhere and other tools can be used on top of it where ppl see that necessary but it is not the way PHP is being developed. Or do you want to change the whole of PHP development at the same time? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
On Fri, Jul 25, 2008 at 5:15 AM, Richard Quadling [EMAIL PROTECTED] wrote: As a windows user my observations/opinions are ... taken with a grain of salt. ;-P Isn't discussion about how to add on to SVN and which tools will be better-suited for development a decade from now counterproductive to the idea at hand? SVN and CVS are the industry standard right now, with SVN being the better-supported and, in many ways, more economical and prudent approach. I'd be afraid that requiring existing and future developers to learn newer technologies would stall several aspects of the project, introduce many new problems, and hinder the advancement of the language as a whole. There's no reason other things couldn't be introduced at a later point, but my personal preference would be to approach the migration one step at a time. Making small bits of progress over time (while simultaneously being able to focus on PHP) seems to be more sensible than trying to radically change everything at once, negating a proven system in favor of what might work better. -- /Daniel P. Brown Better prices on dedicated servers: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GSoC Bugtracker Midterm Update
It was suggested that students write about what they have done and what they aim to achieve by the end So, What have I done, Been working on the new bugtracker, doing more work on classes and behind the scene type things which will hopefully make the bugtracker quick and responsive as well as making it extendable to include new features and the like. What I aim to do, Get basic bug reporting and commenting and the assigning stuff operational, Get email stuff suitable, including subscribe. After and beyond API stuff and restful interface I'm usually rubbish at writing these sorts of things, hence its a little short and tres non-descriptive. Please feel free to ask me questions :-) Bazza -- Barry Carlyon Located Between Al-Jazeera and BBC Radio 1 Webmaster of, http://barrycarlyon.co.uk http://lsrfm.com mobile: 07729 048 443 office: 0113 380 1280 skype: barrycarlyon email: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Bugtracker Midterm Update
Hello Barry, Friday, July 25, 2008, 8:37:01 PM, you wrote: It was suggested that students write about what they have done and what they aim to achieve by the end So, What have I done, Been working on the new bugtracker, doing more work on classes and behind the scene type things which will hopefully make the bugtracker quick and responsive as well as making it extendable to include new features and the like. What I aim to do, Get basic bug reporting and commenting and the assigning stuff operational, Get email stuff suitable, including subscribe. After and beyond API stuff and restful interface I'm usually rubbish at writing these sorts of things, hence its a little short and tres non-descriptive. Please feel free to ask me questions :-) Thanks for the work. Once the GSoC is over you have to write a bit more fear :-) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] __toBoolean()
Hello troels,
Friday, July 25, 2008, 5:04:31 PM, you wrote:
First, apologies if this has been discussed before. I couldn't find
any evidence to suggest that it has, but it kind of surprises me.
As strings aren't objects in PHP, __toString is quite a useful
construct, but it begs the question as to why there aren't
__toprimitve-type for each of the primitive types in PHP? Through
SPL, we have __toArray covered, and I presume that there is no real
value in a __toInteger or __toFloat, but __toBoolean seems as it could
be quite useful, since it would allow an object to be evaluated in a
conditional. Eg. a simple use-case:
class Validation {
protected $errors = array();
function fail($error) {
$this-errors[] = $error;
}
function __toBoolean() {
return count($this-errors) === 0;
}
}
I wonder if the reason why this haven't been suggest yet is because of:
a) Nobody thought about it before
b) Somebody thought about it, and figured out that it was a bad idea
While this looks pretty simple, I have a hunch that introducing such
behaviour could have far-fetching consequences, as it hooks into PHP's
dynamic typing system. It also have a smell of C++'s ability to
overload operators and the ensuing shooting of feet. On the other
hand, it does allow some nifty tricks, and as it's optional,
presumably people would only use it when it actually makes sense.
Even if this, for some reason, doesn't fit into core PHP, it might be
a candidate for SPL? (Even if the syntax would then be slightly
different)
No, there is SPL_Types in pecl which is a good place for type stuff.
Actually SPL_Types allows objects that behave as booleans.
Other than that we do not want this type of conversion support and it was
discussed before and rejected every single time.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Bugtracker Midterm Update
On Fri, Jul 25, 2008 at 2:37 PM, Barry Carlyon [EMAIL PROTECTED] wrote: It was suggested that students write about what they have done and what they aim to achieve by the end Can you name specifically three things you've learned during the first half of the summer that you didn't know before? For example: working on this project also gave you familiarity with working with a group and meeting deadlines; the project taught you how to work with version control software; you developed a more intimate knowledge of the PHP internals; et cetera. We know what we're getting out of the experience with your involvement with the project, I'm just curious as to how it's working out on your end. -- /Daniel P. Brown Better prices on dedicated servers: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hello Christian, patch looks fine and should go in. do you think ReflectionMethod::__construct implementation could be done using parameterparsing 'f' rather than the spcial case 'o'? Unfortunately we would still need the zs version unless we add another 'F' parameter parsing that allows this two parameter case as well. marcus Friday, July 25, 2008, 5:41:49 PM, you wrote: Hi, http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch The last CVS commit for apply_func_t and TSRMLS_CC conflicted with the patches, I merged the conflicting line manually and reuploaded the patches to the same location. Regards, Christian Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hi Marcus, patch looks fine and should go in. Thanks. do you think ReflectionMethod::__construct implementation could be done using parameterparsing 'f' rather than the spcial case 'o'? The Problem with 'f' is that it will accept every callback, even normal functions, so that would kind of break the idea of having ReflectionMethod different than ReflectionFunction. So in my eyes, using 'o' for now is the sanest approach. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [GSoC] Report (PhD student)
Hi folks! As Derick asked us for, here is my progress report. I am Rudy Nappée, a french 21 years old guy, I use PHP since 5 or 6 years ago. I began the May 26th to work for PhD (PHP-based Docbook Renderer) project, mentored by Hannes Magnusson (bjori). My GSoC proposal was: * To write new output formats: CHM, Manpages, PDF * To write themes: PEAR HTML theme, PHP-GTK HTML theme * To design DBHTML implementation in PhD Currently, I'm done with CHM and Manpages formats (and its own PHP themes) and PEAR theme. PDF output is almost done (probably this weekend or next week). I have until August 11st (suggested end of project) or August 18th (firm 'pencil down' date) to work on the PHP-GTK theme and the DBHTML implementation. I feel on tracks^^ I did not have big difficulties or issues with the project and am glad to work with PHP Doc guys. I think I'll continue after GSoC. Here it is, if you have questions about my work, please email me or come to #php.doc and if you wan't to view my weekly report status or see some results (pdf output for example), I invite you to view my blog : http://loudi-soc.blogspot.com Regards Rudy Nappée -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hello Christian, Friday, July 25, 2008, 9:01:13 PM, you wrote: Hi Marcus, patch looks fine and should go in. Thanks. do you think ReflectionMethod::__construct implementation could be done using parameterparsing 'f' rather than the spcial case 'o'? The Problem with 'f' is that it will accept every callback, even normal functions, so that would kind of break the idea of having ReflectionMethod different than ReflectionFunction. So in my eyes, using 'o' for now is the sanest approach. I see. So if we ever want to fix it we need 'm' for method then :-) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Hello Marcus; Marcus Boerger wrote: A cvs read-only mirror would be nice to allow the old way of checking out stuff. But there I fail to see the reason to limit our selves to one additional other tool, nor do I see a reason to complicate matters even more by giving people other repositories that we somehow merge or not. SVN works everywhere and other tools can be used on top of it where ppl see that necessary but it is not the way PHP is being developed. Or do you want to change the whole of PHP development at the same time? I don't presume to speak for Lukas here, nor to believe we should standardize on one particular alternative VCS (be it a DVCS or not). I think we should definitely go the SVN route as the only official way to commit to PHP with possibly a read-only mirror on CVS that could be phased out at some point in the future. That said, I think if someone is willing to step up to the plate and offer bootstrap repositories for another VCS and is willing to help support it for those who are interested in using it we would be remiss in turning them down as it's no small undertaking. According to the wiki there are over 270k commits in php-src. Using Mono (90k - 100k commits) and my own experience with smaller repositories (500 - 30k) as a guide, this means that to clone the entire history of PHP via a `git svn clone` command would take nearly a week! Using a bootstrap that is updated nightly, or even weekly, we can cut that process down to 15 minutes. I've already volunteered on the svn-migrations list to work on an unofficial mirror as soon as the SVN import is completed. I would love to see it make its way onto a php.net server so others who are interested can benefit from the upfront work, but will be happy to host it on one of my servers like the current git clone is. -T -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [GSoC] Report (PhD student)
Hello Nappee, Friday, July 25, 2008, 9:07:58 PM, you wrote: Hi folks! As Derick asked us for, here is my progress report. I am Rudy Nappée, a french 21 years old guy, I use PHP since 5 or 6 years ago. I began the May 26th to work for PhD (PHP-based Docbook Renderer) project, mentored by Hannes Magnusson (bjori). My GSoC proposal was: * To write new output formats: CHM, Manpages, PDF * To write themes: PEAR HTML theme, PHP-GTK HTML theme * To design DBHTML implementation in PhD Currently, I'm done with CHM and Manpages formats (and its own PHP themes) and PEAR theme. PDF output is almost done (probably this weekend or next week). I see new books coming I have until August 11st (suggested end of project) or August 18th (firm 'pencil down' date) to work on the PHP-GTK theme and the DBHTML implementation. I feel on tracks^^ I did not have big difficulties or issues with the project and am glad to work with PHP Doc guys. I think I'll continue after GSoC. Great!!! :-) Here it is, if you have questions about my work, please email me or come to #php.doc and if you wan't to view my weekly report status or see some results (pdf output for example), I invite you to view my blog : http://loudi-soc.blogspot.com Regards Rudy Nappée Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
On 25.07.2008, at 20:56, Marcus Boerger wrote: Hello Christian, patch looks fine and should go in. do you think ReflectionMethod::__construct implementation could be done using parameterparsing 'f' rather than the spcial case 'o'? Unfortunately we would still need the zs version unless we add another 'F' parameter parsing that allows this two parameter case as well. marcus Friday, July 25, 2008, 5:41:49 PM, you wrote: Hi, http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch if this isnt commited yet .. could someone handle this ASAP? Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [GSoC] Report (PhD student)
On Fri, Jul 25, 2008 at 21:07, Nappee Rudy [EMAIL PROTECTED] wrote: * To write new output formats: CHM, Manpages, PDF * To write themes: PEAR HTML theme, PHP-GTK HTML theme * To design DBHTML implementation in PhD Its worth mentioning that the CHM and Unix man page outputs are in the latest PhD release \o/ As a quick side project he even committed kdevelop TOC output format after a recent request for it :) Furthermore the peardoc guys are these days trying to figure out which box is doing their doc builds so they can test out the pear themes. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/stan ... Deprecate ticks, pcntl_signal affected?
Hi, [CCing interested parties based on the last mail exchange on this topic] will the deprecation of ticks affect the usage of pcntl_signal? The manual says [1] ... As of PHP 4.3.0 PCNTL uses ticks as the signal handle callback mechanism Current practice requires to declare(ticks = 1); for pcntl_signal to work. No ticks, no signal handling? thanks, - Markus [1] http://us.php.net/manual/en/function.pcntl-signal.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Bugtracker Midterm Update
1) working with object orientated properly, writing classes and the like, this is my first time using classes that I have written, 2) working with version control, git and cvs, I publish to my git local repo, and then push to CVS, I have some nice alias functions on my box to make it quicker, 3) More difficult to pick something, for item 3, there is a lot I have learned, expanding my PHP, SQL (mysqli) knowledge, as well as all the team stuff and working with the team in a different way, I mean looking at them as users, rather than team members No doubt I will add to this soon :-) Daniel Brown wrote: On Fri, Jul 25, 2008 at 2:37 PM, Barry Carlyon [EMAIL PROTECTED] wrote: It was suggested that students write about what they have done and what they aim to achieve by the end Can you name specifically three things you've learned during the first half of the summer that you didn't know before? For example: working on this project also gave you familiarity with working with a group and meeting deadlines; the project taught you how to work with version control software; you developed a more intimate knowledge of the PHP internals; et cetera. We know what we're getting out of the experience with your involvement with the project, I'm just curious as to how it's working out on your end. -- Barry Carlyon Located Between Al-Jazeera and BBC Radio 1 Webmaster of, http://barrycarlyon.co.uk http://lsrfm.com mobile: 07729 048 443 office: 0113 380 1280 skype: barrycarlyon email: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Bugtracker Midterm Update
On Fri, Jul 25, 2008 at 6:53 PM, Barry Carlyon [EMAIL PROTECTED] wrote: 1) working with object orientated properly, writing classes and the like, this is my first time using classes that I have written, 2) working with version control, git and cvs, I publish to my git local repo, and then push to CVS, I have some nice alias functions on my box to make it quicker, 3) More difficult to pick something, for item 3, there is a lot I have learned, expanding my PHP, SQL (mysqli) knowledge, as well as all the team stuff and working with the team in a different way, I mean looking at them as users, rather than team members 4.) Not to top-post ;-P -- /Daniel P. Brown Better prices on dedicated servers: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Bugtracker Midterm Update
Top-post? Daniel Brown wrote: On Fri, Jul 25, 2008 at 6:53 PM, Barry Carlyon [EMAIL PROTECTED] wrote: 1) working with object orientated properly, writing classes and the like, this is my first time using classes that I have written, 2) working with version control, git and cvs, I publish to my git local repo, and then push to CVS, I have some nice alias functions on my box to make it quicker, 3) More difficult to pick something, for item 3, there is a lot I have learned, expanding my PHP, SQL (mysqli) knowledge, as well as all the team stuff and working with the team in a different way, I mean looking at them as users, rather than team members 4.) Not to top-post ;-P -- Barry Carlyon Located Between Al-Jazeera and BBC Radio 1 Webmaster of, http://barrycarlyon.co.uk http://lsrfm.com mobile: 07729 048 443 office: 0113 380 1280 skype: barrycarlyon email: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GSoC Optimizer Update
Hi, My Google Summer of Code project is to develop and release an initial version on the optimizer originally being developed by Ilia. The optimizer will be released to PECL as its own extension, however, it will require APC in order to run. Ive worked on cleaning up bugs and testing the existing code. In addition I have worked on refactoring some of the code to provide a base on which to build a more powerful and more robust optimizer. I have added a few additional optimizations including: 1) Optimization of basic math identities 2) Optimization of silence blocks 3) More functions for which we can pre-calculate return values for if they have all static parameters. (substr, acos, acosh, asin, asinh, atan, atanh, cos, cosh, sin, sinh, tan, tanh, exp, log10, sqrt, atan2, ceil, floor, fmod, ini_get [for PHP_INI_SYSTEM values only], ip2long, long2ip, trim, chop, rtrim, ltrim, rad2deg, deg2rad, abs) 4) worked on making function optimization more aggressive to reduce the number of required passes for full optimization. 5) A few more minor things here and there There are plans to change the optimizer hook in APC over to adding a new compile layer. This should help give the optimizer better control as well as make it more easily integrateable with other extensions. In the future I would like to work on a new control system and new analysis tools for the optimizer. Hopefully such eventual changes will open up the way for more powerful optimizations down the road. In addition there are some APC specific optimizations that might be able to be done. Hopefully the initial release of the optimizer will in available in PECL in the next few weeks. For now you can get it from pecl/optimizer in CVS. ~ Graham
