[PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
Hi Matt, Matt Wilmas wrote: Hi again Dmitry, Just wanted to say that I think I can make your code a bit smaller after looking at it closer. It would be great, but keep in mind that performance is more important. Don't quite have enough time to modify and verify it now, but I'll be back later (around the usual time) to let you know either way. :-) I'm waiting for your changes. Thanks. Dmitry. - Matt - Original Message - From: Dmitry Stogov Sent: Wednesday, March 18, 2009 Hi Matt, I suppose I fixed the patch. Could you please check which patch is better yours or the attached one? According to attached benchmark my one is faster for most usual cases, but may be I forget something again. $a[abcdefghij] 0.130 0.130 $a[1234567890] 0.187 0.104 $a[2147483648] 0.168 0.142 $a[0]0.116 0.082 $a[214748364x] 0.136 0.141 $a[0] 0.080 0.080 Also, do you have other patches which I could look into before RC? Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSOC Idea, RPC Server
On Wed, Mar 18, 2009 at 10:55 PM, Cesar D. Rodas sad...@gmail.com wrote: In the presentation with Gearman you have a C extension for PHP, and you code the daemon itself in PHP. My idea it's different. Let's put it simple. I am planning code a server (similar to a web server, Apache) written in C or C++ that contains PHP embed (or its own SAPI), with an efficient protocol (no xml, no http) to call PHP functions that he contains. The protocol probably would use my binary serialization class and submit objects (http://www.phpclasses.org/browse/package/5242.html) but I don't know yet. So basically a php executable daemon you could connect to and if it was plaintext protocol type: ?php echo hi; ? and it would execute? In typical installation you would have many workers, and one master that will be a mere php application with web interface probably that would submit PHP code to the workers. The code will be raw PHP, I mean no special API would be needed to export any function, my goal it's keep it simple to migrate. The final client wouldn't connect to the master, they will have a pull of worker and they will pick up one randomly (as many people does with memcached). Is it clear enough? I think so. Although I'm not quite sure I see the need for it, when solutions like Gearman exist and are already built-in with many features like transactions (I believe it's in there) and first-come-first-serve and possible all-workers-execute mentalities... why not leverage the Gearman's projects learnings and now newfound speed in C...? To me this sounds like a possible security hole as someone could write a client to basically execute arbitrary PHP on any server, if I understood it right. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Production and development ini changes.
Eric Stewart wrote: I've attached patches for php.ini-production and php.ini-development. One change involves an mbstring setting correction regarding: http://marc.info/?l=php-cvsm=123596904426621w=2 http://marc.info/?l=php-cvsm=123596904426621w=2 Another change adds an additional comment including XOR in the list of usable bitwise operators. The final change includes a note regarding the merge of E_STRICT into E_ALL in PHP 6.0.0. Eric Lee Stewart ericleestew...@gmail.com mailto:ericleestew...@gmail.com Hi Eric, I wonder if my mails to you are getting through (e.g. the one mentioning mbstring.http_output_conv_mimetype? In anycase, I don't think your patch was attached. Can you save it as a .txt file and resend it? Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSOC Idea, RPC Server
2009/3/19 mike mike...@gmail.com:
On Wed, Mar 18, 2009 at 10:55 PM, Cesar D. Rodas sad...@gmail.com wrote:
In the presentation with Gearman you have a C extension for PHP, and
you code the daemon itself in PHP. My idea it's different. Let's put
it simple. I am planning code a server (similar to a web server,
Apache) written in C or C++ that contains PHP embed (or its own SAPI),
with an efficient protocol (no xml, no http) to call PHP functions
that he contains. The protocol probably would use my binary
serialization class and submit objects
(http://www.phpclasses.org/browse/package/5242.html) but I don't know
yet.
So basically a php executable daemon you could connect to and if it
was plaintext protocol type:
?php
echo hi;
?
and it would execute?
No, i.e The master process send to every worker (only the master can send code).
?php
function send_email($to,$subject,$text) {
mail($to,$subject,$text);
return 5;
}
phpserver::export(send_mail);
?
And a client can execute it by:
?php
phpserver::add_worker(x.x.x.x:0);
$return = rpc(send_email,f...@bar,example subject,example text);
#$return would be 5.
?
In typical installation you would have many workers, and one master
that will be a mere php application with web interface probably that
would submit PHP code to the workers. The code will be raw PHP, I mean
no special API would be needed to export any function, my goal it's
keep it simple to migrate.
The final client wouldn't connect to the master, they will have a pull
of worker and they will pick up one randomly (as many people does with
memcached).
Is it clear enough?
I think so. Although I'm not quite sure I see the need for it, when
solutions like Gearman exist and are already built-in with many
features like transactions (I believe it's in there) and
first-come-first-serve and possible all-workers-execute mentalities...
why not leverage the Gearman's projects learnings and now newfound
speed in C...?
To me this sounds like a possible security hole as someone could write
a client to basically execute arbitrary PHP on any server, if I
understood it right.
--
Cesar D. Rodas
http://cesar.la/
Phone: +595-961-974165
E. B. White - Be obscure clearly.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSOC Idea, RPC Server
http://www.vl-srm.net/ ? Cesar D. Rodas wrote: 2009/3/19 mike mike...@gmail.com: ... Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GSoC 2009
Hi All, Just a quick note to say that PHP was accepted as an organisation for GSoC 2009. We have until the 23rd of March to try and liaise with any potential students we have available and work on our ideas list that we might suggest. Our ideas list at http://wiki.php.net/gsoc/2009 has a few good ones that have been expanded, there are also some random ideas that need to be filled out. Student applications open on the 23rd of March at 1900 UTC and run until the 3rd of April. Cheers, Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSOC Idea, RPC Server
Hello Andrey, 2009/3/19 Andrey Hristov p...@hristov.com: http://www.vl-srm.net/ ? I've already seen this, and it is pretty similar, but it designs it's very complex IMHO (http://www.vl-srm.net/doc/figures/srm-design.png). My design will be simple, pretty close to the memcached. Part of its simplicity will be only the RPC/RFC functionality, you won't be able to instance remote objects (as the banana class of SRM). My idea it's provide an easy way to scale, you should be able to take an existent project, cut some functions, export into a worker, and hook your app. to the worker(s), I'll also write a little function that will connect to the master process and generate functions that will wrapper as local function, so your code won't change but it would be able to scale. Cesar D. Rodas wrote: 2009/3/19 mike mike...@gmail.com: ... Andrey -- Cesar D. Rodas http://cesar.la/ Phone: +595-961-974165 E. B. White - Be obscure clearly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] un-deprecating ticks ?
Hi, After having seen some complaints about ticks being deprecated I'm wondering if they could be un-deprecated for now. Ticks are used by the pcntl extension to call signal handlers when signals are triggered. I added some functions as an alternative, but this does not covers all use cases (and forces a code change). When searching bug reports about ticks, one can feel the ticks to be broken (and this is why they have been deprecated). However, looking in depth at these bugs and viewing what caused them and how they have been fixed does not show really bad things about ticks. Actually one thing is broken (and is marked as such in the documentation), tick functions do not work in ZTS, this looks fixable. Any thoughts on removing the deprecation warning for now ? (at least until a replacement is found). Sorry for posting this so close to the freeze. Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSOC Idea, RPC Server
On Thu, Mar 19, 2009 at 9:30 AM, Cesar D. Rodas sad...@gmail.com wrote: Hello Andrey, 2009/3/19 Andrey Hristov p...@hristov.com: http://www.vl-srm.net/ ? I've already seen this, and it is pretty similar, but it designs it's very complex IMHO (http://www.vl-srm.net/doc/figures/srm-design.png). My design will be simple, pretty close to the memcached. Part of its simplicity will be only the RPC/RFC functionality, you won't be able to instance remote objects (as the banana class of SRM). My idea it's provide an easy way to scale, you should be able to take an existent project, cut some functions, export into a worker, and hook your app. to the worker(s), I'll also write a little function that will connect to the master process and generate functions that will wrapper as local function, so your code won't change but it would be able to scale. RPC is quite dead http://taint.org/2009/03/18/151218a.html maybe we need something simpler interface like json api for databases http://couchdb.apache.org/docs/overview.html maybe serializing php objects over http ... we need something interesting :) Cesar D. Rodas wrote: 2009/3/19 mike mike...@gmail.com: ... Andrey -- Cesar D. Rodas http://cesar.la/ Phone: +595-961-974165 E. B. White - Be obscure clearly. -- 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] GSOC Idea, RPC Server
2009/3/19 marius adrian popa map...@gmail.com: On Thu, Mar 19, 2009 at 9:30 AM, Cesar D. Rodas sad...@gmail.com wrote: Hello Andrey, 2009/3/19 Andrey Hristov p...@hristov.com: http://www.vl-srm.net/ ? I've already seen this, and it is pretty similar, but it designs it's very complex IMHO (http://www.vl-srm.net/doc/figures/srm-design.png). My design will be simple, pretty close to the memcached. Part of its simplicity will be only the RPC/RFC functionality, you won't be able to instance remote objects (as the banana class of SRM). My idea it's provide an easy way to scale, you should be able to take an existent project, cut some functions, export into a worker, and hook your app. to the worker(s), I'll also write a little function that will connect to the master process and generate functions that will wrapper as local function, so your code won't change but it would be able to scale. RPC is quite dead http://taint.org/2009/03/18/151218a.html I can't figure out a better way to scale, of course this solution wouldn't be for every page, but figure out the problem that great sites such as yahoo, digg, wikipedia, wordpress and others faced to scale. The RPC IMHO is a fast/cheap way to handle huge traffic. maybe we need something simpler interface like json api for database http://couchdb.apache.org/docs/overview.html maybe serializing php objects over http ... we need something interesting :) Can you explain it a little bit more?, this ideas sounds kickass, I'd really love contribute something for PHP Cesar D. Rodas wrote: 2009/3/19 mike mike...@gmail.com: ... Andrey -- Cesar D. Rodas http://cesar.la/ Phone: +595-961-974165 E. B. White - Be obscure clearly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Cesar D. Rodas http://cesar.la/ Phone: +595-961-974165 Samuel Beckett - Birth was the death of him. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSOC Idea, RPC Server
Cesar D. Rodas wrote: 2009/3/19 marius adrian popa map...@gmail.com: On Thu, Mar 19, 2009 at 9:30 AM, Cesar D. Rodas sad...@gmail.com wrote: Hello Andrey, 2009/3/19 Andrey Hristov p...@hristov.com: http://www.vl-srm.net/ ? I've already seen this, and it is pretty similar, but it designs it's very complex IMHO (http://www.vl-srm.net/doc/figures/srm-design.png). My design will be simple, pretty close to the memcached. Part of its simplicity will be only the RPC/RFC functionality, you won't be able to instance remote objects (as the banana class of SRM). My idea it's provide an easy way to scale, you should be able to take an existent project, cut some functions, export into a worker, and hook your app. to the worker(s), I'll also write a little function that will connect to the master process and generate functions that will wrapper as local function, so your code won't change but it would be able to scale. RPC is quite dead http://taint.org/2009/03/18/151218a.html I can't figure out a better way to scale, of course this solution wouldn't be for every page, but figure out the problem that great sites such as yahoo, digg, wikipedia, wordpress and others faced to scale. The RPC IMHO is a fast/cheap way to handle huge traffic. And I can tell you that we don't do this at all. Write your code such that it scales horizontally easily and throw lots of frontend servers with a low number of concurrent connections at it and you end up with a fast scalable site. You will obviously need to hit some central data stores, so there will be some network latency, but with local shared memory caching, you can avoid it on many requests. Taking a network hit for code execution doesn't make sense to me. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
Hi Dmitry, - Original Message - From: Dmitry Stogov Sent: Thursday, March 19, 2009 Hi Matt, Matt Wilmas wrote: Hi again Dmitry, Just wanted to say that I think I can make your code a bit smaller after looking at it closer. It would be great, but keep in mind that performance is more important. I know. :-) Don't quite have enough time to modify and verify it now, but I'll be back later (around the usual time) to let you know either way. :-) I'm waiting for your changes. No patch, but here's the straight code: http://realplain.com/php/handle_numeric.txt With your benchmark script, if I changed one of the keys, it would sometimes radically affect the time of another key value, hmm. But in my own tests, this was always faster. Some notes: I've never understood why the terminating null check is there... I don't see why it would be missing if there aren't other problems in code. A place for UNEXPECTED()? I removed the special handling of 0 and it's faster. (Oh no, I see you just commited your code right now, LOL. Sorry I didn't send this sooner. :-/) For the leading 0 check, I changed it back to length 2 again instead of the end - tmp != 1 calculation. I used ++tmp instead of 2 *tmp++ because I assume having the increment in just one place creates less instructions. ;-) (For size, not speed.) Finally, in the Unicode version (copied, untested), I'm using the 0x values that were there originally instead of '0' char values... Thanks. Dmitry. Again, sorry I was about 20 minutes late with this! :-( - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
So, what is the final conclusion on this one? Are we at a combination of Matt's and Dmitry's patches here? I think we definitely need to fix this even in the 5.2 branch and get it back to 5.1.x and earlier behavior. I consider it a bug that: $arr[35] = 'blah'; print_r($arr); results in: [-2147483648] = blah if someone has written brand new 5.2-specific code that relies on this weird behavior, then we will just have to bite the bullet and break that code. It is way more likely that people are relying on the earlier behavior and will end up with subtle problems in 5.2. I just had someone at Yahoo get bitten by this when they upgraded from 5.1.x to 5.2.x. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
Matt Wilmas wrote: However, nothing has been changed in a 5.2.x release (there was some partial backport shortly before getting reverted). If you noticed a change in 5.2.x, perhaps it was platform related? [1] http://marc.info/?l=php-internalsm=123704111325725w=2 Right, sorry, same people, wrong thread. I don't think it is platform related. The change happened from 5.1 to 5.2, not within the 5.2 cycle. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
Hi Rasmus, - Original Message - From: Rasmus Lerdorf Sent: Thursday, March 19, 2009 So, what is the final conclusion on this one? Are we at a combination of Matt's and Dmitry's patches here? I think we definitely need to fix this even in the 5.2 branch and get it back to 5.1.x and earlier behavior. I consider it a bug that: $arr[35] = 'blah'; print_r($arr); results in: [-2147483648] = blah if someone has written brand new 5.2-specific code that relies on this weird behavior, then we will just have to bite the bullet and break that code. It is way more likely that people are relying on the earlier behavior and will end up with subtle problems in 5.2. I just had someone at Yahoo get bitten by this when they upgraded from 5.1.x to 5.2.x. This thread is about conversion of *numeric string* keys to int/long, rather than double conversion in your example. Bug #45877's behavior has been around forever I think until the fix a couple days ago (5.2 hasn't been changed). With the conversion behavior you're talking about, it sounds like you want the double to long conversion change thread. [1] :-) A change was made there over a year ago in 5.3+, and I've been wondering about what should be expected and how to make that expected behavior consistent across platforms. All details are in that message or the linked ones. However, nothing has been changed in a 5.2.x release (there was some partial backport shortly before getting reverted). If you noticed a change in 5.2.x, perhaps it was platform related? [1] http://marc.info/?l=php-internalsm=123704111325725w=2 -Rasmus - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Late defined classes
Hi all,
This works (albeit with an abstract class error):
---
class Result implements Countable { }
$result = new Result();
---
Switching their order:
---
$result = new Result();
class Result implements Countable { }
---
gives :
---
Fatal error: Class 'Result' not found in /tmp/not_defined.php on line 2
---
If I remove the interface, everything is peachy:
---
$result = new Result();
class Result { }
---
So as a user of PHP I was quite surprised that a class with an interface
must be in the code flow to be defined.
Is there anything (easy) that we can do to support this case?
Thanks
Paul
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
