[PHP-DEV] How to get script filename in module RINIT function
Hi all! I am developing a small PHP extension and I ATM can't figure out how to get to $_SERVER['SCRIPT_FILENAME'] content while in PHP_RINIT or PHP_RSHUTDOWN function. Can someone please hint me with this one? Thanks, b.
Re: [PHP-DEV] Indexing an array
On 08/06/2010 04:42 PM, Gustavo Lopes wrote: On Fri, 06 Aug 2010 15:33:18 +0100, mathieu.suen mathieu.s...@easyflirt.com wrote: Hi, For now you can only index an array using a scalar type or a string. Is there some rfc or work going on to enlarge the possibility so that it is possible to have some other object like: - closure - object - etc. I think the problem with that is how you are going to generate the hash of arbitrary objects in order to store them in the hash table. It's not like all PHP objects have a hashCode() method. IMHO It should. So the only plausible option would be to attribute the same hash to all and the test all for equality on an insertion with a new key or in the worst case scenario for updates and reads. Since php is not referentially transparent I would rather use identity unless object can redefine equality. -- Mathieu Suen
Re: [PHP-DEV] Indexing an array
On 08/06/2010 04:44 PM, Richard Quadling wrote:
On 6 August 2010 15:33, mathieu.suenmathieu.s...@easyflirt.com wrote:
Hi,
For now you can only index an array using a scalar type or a string.
Is there some rfc or work going on to enlarge the possibility so that it is
possible to have some other object like:
- closure
- object
- etc.
Thanks
-- Mathieu Suen
If an object implements a __toString() magic method, then it can work ...
?php
class randomizer {
public function __toString() {
return (string)mt_rand();
}
}
$randomizer = new randomizer;
$array = array (
$randomizer = 'First',
$randomizer = 'Second',
$randomizer = 'Third',
$randomizer = 'Fourth',
);
print_r($array);
?
outputs ...
Array
(
[1365443950] = First
[1235256771] = Second
[520059180] = Third
[486985268] = Fourth
)
Well that is not the expected behavior since if you call array_keys you
won't get the object.
--Mathieu Suen
Re: [PHP-DEV] Indexing an array
On 08/06/2010 07:46 PM, Stas Malyshev wrote: Hi! For now you can only index an array using a scalar type or a string. Is there some rfc or work going on to enlarge the possibility so that it is possible to have some other object like: I think SplObjectStorage implements most common use-case for such behavior, do you have any other one that is not covered there and can't be done by __toString()? Yes but what I don't like with the Spl is that it does not work with the array_* function and the sort function. -- Mathieu Suen
Re: [PHP-DEV] Indexing an array
On Mon, 2010-08-09 at 13:47 +0200, mathieu.suen wrote:
outputs ...
Array
(
[1365443950] = First
[1235256771] = Second
[520059180] = Third
[486985268] = Fourth
)
Well that is not the expected behavior since if you call array_keys you
won't get the object.
Well, arrays are implemented as hash tables, hash tables work by
generating a hash to identify a value. Changing this is a big change
(rewrite everything accessing array keys) and you can always do
something like
$array = array(
spl_object_hash($object1) = array('object' = $object1, 'data' = /* ...*/),
spl_object_hash($object2) = array('object' = $object2, 'data' = /* ...*/),
/*...*/
);
The only thing I can imagine is that we add support for objects
implementing ArrayAccess and Traversable (Iterator) on more places.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get script filename in module RINIT function
On Mon, 2010-08-09 at 13:32 +0200, Bostjan Skufca wrote:
Hi all!
I am developing a small PHP extension and I ATM can't figure out how to get
to $_SERVER['SCRIPT_FILENAME'] content while in PHP_RINIT or PHP_RSHUTDOWN
function. Can someone please hint me with this one?
The simple answer is: You can't. The closest you can get is a char *
SG(request_data).request_uri
The more complex answer is: It is only stored for being used in
$_SERVER. So you can read it from there. The engine has a just in time
mode to avoid creating _SERVER when not needed, we need it so we first
have to trigger the creation of that variable, then one can search
through the global symbol table and then search in there:
zval **server, **tmp;
zend_auto_global_disable_jit(_SERVER, sizeof(_SERVER)-1 TSRMLS_CC);
if (zend_hash_find(EG(symbol_table), _SERVER, sizeof(_SERVER),
(void**)server) == FAILURE || Z_TYPE_PP(server) != IS_ARRAY) {
/* error handling */
return;
}
if (zend_hash_find(Z_ARRVAL_PP(server), SCRIPT_FILENAME,
sizeof(SCRIPT_FILENAME), (void**)tmp) == FAILURE || Z_TYPE_PP(tmp) !=
IS_STRING) {
/* error handling */
return;
}
/* work with tmp */
As this accesses the userspace $_SERVER you should do this during RINIT,
else the value might be wrong. While this adds some cost to every
request (populating $_SERVER plus two hash lookups), it can be optimized
a tiny bit by precalculating the hash and using zend_hash_quick_find().
The code above is untested.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get script filename in module RINIT function
I don't think I made myself exactly clear.
There are 2 use cases I would like to consider:
1. CLI: by using php /full/path/to/script.php or cd /full/path/to php
script.php
2. Apache DSO: going to http://www.domain.com/script.php which in turn
'executes' script /full/path/to/script.php
In both cases, in RINIT I would like to get full path (real path, if
possible) of this /full/path/to/script.php. Is this possible or is your way
the only viable solution (with performance penalty etc)?
(The $_SERVER['SCRIPT_FILENAME'] was just a method to explain what I would
like to have, albeit obviously a poor one:)
Thanks again,
b.
2010/8/9 Johannes Schlüter johan...@php.net
On Mon, 2010-08-09 at 13:32 +0200, Bostjan Skufca wrote:
Hi all!
I am developing a small PHP extension and I ATM can't figure out how to
get
to $_SERVER['SCRIPT_FILENAME'] content while in PHP_RINIT or
PHP_RSHUTDOWN
function. Can someone please hint me with this one?
The simple answer is: You can't. The closest you can get is a char *
SG(request_data).request_uri
The more complex answer is: It is only stored for being used in
$_SERVER. So you can read it from there. The engine has a just in time
mode to avoid creating _SERVER when not needed, we need it so we first
have to trigger the creation of that variable, then one can search
through the global symbol table and then search in there:
zval **server, **tmp;
zend_auto_global_disable_jit(_SERVER, sizeof(_SERVER)-1 TSRMLS_CC);
if (zend_hash_find(EG(symbol_table), _SERVER, sizeof(_SERVER),
(void**)server) == FAILURE || Z_TYPE_PP(server) != IS_ARRAY) {
/* error handling */
return;
}
if (zend_hash_find(Z_ARRVAL_PP(server), SCRIPT_FILENAME,
sizeof(SCRIPT_FILENAME), (void**)tmp) == FAILURE || Z_TYPE_PP(tmp) !=
IS_STRING) {
/* error handling */
return;
}
/* work with tmp */
As this accesses the userspace $_SERVER you should do this during RINIT,
else the value might be wrong. While this adds some cost to every
request (populating $_SERVER plus two hash lookups), it can be optimized
a tiny bit by precalculating the hash and using zend_hash_quick_find().
The code above is untested.
johannes
Re: [PHP-DEV] Indexing an array
On Mon, 09 Aug 2010 12:44:03 +0100, mathieu.suen mathieu.s...@easyflirt.com wrote: On 08/06/2010 04:42 PM, Gustavo Lopes wrote: On Fri, 06 Aug 2010 15:33:18 +0100, mathieu.suen mathieu.s...@easyflirt.com wrote: For now you can only index an array using a scalar type or a string. Is there some rfc or work going on to enlarge the possibility so that it is possible to have some other object like: - closure - object - etc. I think the problem with that is how you are going to generate the hash of arbitrary objects in order to store them in the hash table. It's not like all PHP objects have a hashCode() method. IMHO It should. So the only plausible option would be to attribute the same hash to all and the test all for equality on an insertion with a new key or in the worst case scenario for updates and reads. Since php is not referentially transparent I would rather use identity unless object can redefine equality. Well, even if one could overcome the hash problem by using suboptimal methods like calling __toString (or even use spl_object_hash(), though we'd be limited to identity) as if they were hashCode() methods, one big problem remains: the hash tables only store a simple integer (for numerical indexing) or a char * string (for string indexing) to identify the key. It would have to be changed to be able to store an object, and now we'd break a lot of code that expects keys to be either strings or integers, not to mention the arrays API would be more complicated that it already is. SplObjectStorage is a so-so alternative because it only allows identity in indexing, but you seem to be OK with that. As to it not working with array functions, you're right, it sucks. In fact, only array_key_exists and array_walk(_recursive) work with object (if you can call it work). Perhaps one path here is to change the array functions so that if they receive an object they try to cast it into an array with the cast_object handler/convert_object_to_type and change the current default implementation for standard objects, which only handles conversions to string, to also handle conversions to arrays by traversing the object, if possible. Not the most efficient thing to do, since it requires copying everything, but it would be easier than changing the array functions in a more profound fashion. The H parse argument is useless because it tries to call get_properties (by the way, I don't understand why convert_to_array(_ex) and convert_to_explicit_type prefer get_properties to cast_object). -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: APC in trunk
Just a ping on this one, with the 3.1.4 release would anyone be in favour of moving it into trunk now? If not, then I can do it with some help from someone who have moved a pecl extension into core before. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 Alpha?
Greetings geeks With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
hi, Huge -1 here. We are light years away to even be able to define what will be php-next. Let discuss that September, at the soonest. Cheers, On Mon, Aug 9, 2010 at 11:56 PM, Kalle Sommer Nielsen ka...@php.net wrote: Greetings geeks With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: APC in trunk
hi, It is still beta. But Gopal and Rasmus should decide when it is ready. On Mon, Aug 9, 2010 at 11:54 PM, Kalle Sommer Nielsen ka...@php.net wrote: Just a ping on this one, with the 3.1.4 release would anyone be in favour of moving it into trunk now? If not, then I can do it with some help from someone who have moved a pecl extension into core before. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: APC in trunk
On Aug 9, 2010, at 4:29 PM, Pierre Joye wrote: hi, On Mon, Aug 9, 2010 at 11:54 PM, Kalle Sommer Nielsen ka...@php.net wrote: Just a ping on this one, with the 3.1.4 release would anyone be in favour of moving it into trunk now? If not, then I can do it with some help from someone who have moved a pecl extension into core before. It is still beta. But Gopal and Rasmus should decide when it is ready. Moving an extension from PECL to Core has side effects, like typically the PECL version dies. APC is not ready for that, so I don't think it's time. Well, I think many extensions should live in PECL and be bundled during the release process (instead of being moved into core at all) but that's another story Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
答复: [PHP-DEV] 5.4 Alpha?
http://news.php.net/php.internals/49186 I hope 5.4 beta complete support LFS. -邮件原件- 发件人: kalle@gmail.com [mailto:kalle@gmail.com] 代表 Kalle Sommer Nielsen 发送时间: 2010年8月10日 5:56 收件人: Internals 主题: [PHP-DEV] 5.4 Alpha? Greetings geeks With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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
[PHP-DEV] SVN Account Request: kriscraig
Currently, I'm working on several parallel feature additions to the date extension. Specifically with regard to accurate calculation of seasonal equinox, an added paremeter character to display the current season in the date() function, limited hemisphere detection based on the timezone setting and/or latitude setting, etc. I am also looking into tackling some related bugs, TODOs, PHPT tests, etc. Far too much going on to toss around a bunch of patches left and right, though I can send a small sample patch of one of the things I'm working on to demonstrate my competence upon request. For right now, I'd just need access to the php-src/.../ext/date portion of the repository, though later on I'll probably want access elsewhere in the repo to work on other things as well, though for now that isn't necessary. And finally, I understand the licensing requirements and will not be committing any work linked to GPL/LGPL stuff (everything I've been doing thus far is self-authored anyway). Please let me know if you have any additional questions/etc. I look forward to contributing my talents to this wonderful community! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
On 10 August 2010 07:28, Pierre Joye pierre@gmail.com wrote: On Mon, Aug 9, 2010 at 11:56 PM, Kalle Sommer Nielsen ka...@php.net wrote: With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. Huge -1 here. We are light years away to even be able to define what will be php-next. Let discuss that September, at the soonest. I could not disagree more. I think one of the key lessons we should have learned out of the whole 6.0 saga was that release early, release often is a good thing, and I don't see much on the RFC list or that's been discussed recently on Internals that's going to be significantly advanced if we leave even discussing it another month or more. I think it's time to make a few decisions on what's in and what's out and move on. Trunk doesn't seem to be in a bad state, all told, so I'd love to see a 5.3+δ alpha next month (presumably towards the end of it) — that doesn't imply a feature freeze, or remove the possibility to change things later, but it does tell developers that we're pretty serious about what's in trunk, and that we want people to start playing with some of the new features like traits to see how it effects them and start reporting bugs. Bear in mind, too, that even with a September alpha, we'd still be looking at a release early next year at the earliest. Even on the quickest timeline I could imagine — a couple of alphas, maybe a first beta on the run down to Christmas, another beta or two early next year, then some RCs — I can't see a stable release until autumn (OK, spring for most of you: March-May) next year, which would be the best part of two years after 5.3.0. Remember, that's assuming we move fast, and history's against us there. :) Adam, who looks forward to getting flamed on IRC later for writing another long screed. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: APC in trunk
On 08/10/2010 01:57 AM, Philip Olson wrote: Moving an extension from PECL to Core has side effects, like typically the PECL version dies. Sadly, this is very true. Well, I think many extensions should live in PECL and be bundled during the release process (instead of being moved into core at all) but that's another story This would really make sense! I'd help out if we could get anywhere down that road. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
