[PHP-DEV] Static library binding
Hi, I have a kind of stupid question. I run PHP inside a fpm chroot jail for a lot of vhosts, each vhost with it's own pool. Unfortunatley, I can't connect to remote domains neither via the native file api (assumed allow_url_fopen is on) nor via curl. I don't want to copy all the libs into the jails. So, is there an easy way to link the needed dns libs statically to PHP? For ease of use, this could be a nice configure parameter, like link it chroot compatible. It must, of course, be made clear that the user is responsible for security updates of the libraries. Thanks Robert
[PHP-DEV] Shebang parsing
Hi, I currently work on a daemon implemented in PHP and as such, I want to keep all configurations in place while the php binary can be used by other cli scripts with the default /etc/php.ini file. I could recompile PHP and add a new folder to the folder which is scanned for php.ini files. A better idea would be a configuration with the shebang like this: #!/usr/local/php/bin/php -c /var/www/php.ini Unfortunately, this doesn't work on Linux due to a delbug/del insfeature/ins which keeps the shebang parameters as one string on argv[1]. There is already a ticket for this problem: https://bugs.php.net/bug.php?id=53034 My specific problem could be tackled in two ways: - Scan . every time cli is called for a php.ini file or - Try to make argv interpretation more intelligent and parse/merge shebang parameters. The second solution, would also open the possebility to define constants or make use of all other cli parameters. Well, there's also a quick hack. We could change php_getopt() in order to make this a valid argument: php -c=/var/www/php.ini Anyway, I would provide a patch for the shebang parsing, but I wanted to put out my feelers what you think about this idea in general. I know, it's an OS problem, but we could work around this problem very quickly and improve the usability of cli scripts alot. Robert
Re: [PHP-DEV] foreach() for strings
1. The number of CHARs isn't unrelevant in a general manner. It depents on the application, even if the trend goes towards UTF8 for websites. 2. Within 10 years, you could have come to a working solution which could please us all. 3. Stop flaming and focus on your other day-job instead. 2011/6/22 Reindl Harald h.rei...@thelounge.net Am 22.06.2011 16:49, schrieb Ferenc Kovacs: after 10 years i want solutions where it is not the road to hell using any string function on user-input and since PHP6 seems to be quite dead it feels there will never be a trustable solution you made my day. boy :) after fetch a mail-client which does not convert plain-text to html tell me how long should we wait until as example strlen() does return the number of CHARS instead bytes because this low level information is not needed on the script side and simply wrong by multibyte input what happended with PHP6?
Re: [PHP-DEV] Re: foreach() for strings
And what actually failed? The idea seams straightforward. Robert 2011/6/20 Johannes Schlüter johan...@schlueters.de On Mon, 2011-06-20 at 20:38 +0200, Robert Eisele wrote: I really like the ideas shared here. It's a thing of consideration that array-functions should also work with strings. Maybe this would be the way to go, but I'm more excited about the OOP implementation of TextIterator and ByteIterator, which solves the whole problem at once (and is easier to implement, as mentioned by Stas). As Jonathan said, Database results with a certain encoding could get iterated, too. The only way to workaround the Text/Byte problem would be, offsetting EVERY string with 1-2 byte string-type information or an additional type flag in the zval-strcuture. Handling everything with zval's instead of objects would have the advantage, that database-layers like mysqlnd could write the database-encoding directly into the zval and the user had no need to decide what encoding is used. Welcome back to the failed PHP 6 Unicode project. ;-) (while we didn't store the original encoding but converted to Utf-16, which prevents random/strange conversions in other places when mixing encodings) johannes
[PHP-DEV] Standard constants as part of the lexer
The constants true, false and null are used very often. Unfortunately, every usage of either of these constants invokes a constant lookup. There is no problem with this, constant lookups are fast, but I nevertheless implemented these constants directly in the lexer to avoid these lookups. I'd be glad to see this change in 5.4 as the performance enhancement would be a steal. I've also added a new OP code to hard-code count() and strlen() which improves the performance by ~800%. This is nice, but limits the usage of count() and strlen() as method name - if no further changes will be made at the parser. I would rather see a optimization for every function call in 5.4.x. I'll take a look at this soon, maybe I can provide a patch for this, too. What do you think about the constants optimization? Unfortunateley, I've broken the power cable of my macbook and have to wait for a new one. I'll deliver in addition the patch if you like the idea. Robert
[PHP-DEV] Optimized smart strings
PHP makes use of the smart string library. I've optimized the smart_str_append_long() macro in order to save one division per cycle. At the moment one modulo and one division is used. The optimized version uses one division (which gets optimized away in most situations) and one additional multiplication + subtraction. I've additionally added also a new maco called smart_str_append_const(). This macro is used to append constant strings with a sizeof()-1 instead of strlen() call. I'd be glad to see this change in 5.4. As I wrote in the earlier post, I'll deliver the patch in addition. PS: yes, this is a really small micro optimization. Robert
Re: [PHP-DEV] Standard constants as part of the lexer
2011/6/20 Derick Rethans der...@php.net
On Mon, 20 Jun 2011, Robert Eisele wrote:
The constants true, false and null are used very often. Unfortunately,
every usage of either of these constants invokes a constant lookup.
There is no problem with this, constant lookups are fast, but I
nevertheless implemented these constants directly in the lexer to
avoid these lookups. I'd be glad to see this change in 5.4 as the
performance enhancement would be a steal.
Would that not break the following code?:
?php
class bar
{
function true()
{
return true;
}
}
$A = new bar;
$A-true();
?
Yes, indeed. But as I wrote, we could add T_SIZEOF (symbol for count +
strlen) and T_LVAL (used for constants) as exception for method and function
names. A more general solution would be better, instead of hacking such
things without deep considerations in an official tree.
I've also added a new OP code to hard-code count() and strlen() which
improves the performance by ~800%. This is nice, but limits the usage
of count() and strlen() as method name - if no further changes will be
made at the parser. I would rather see a optimization for every
function call in 5.4.x. I'll take a look at this soon, maybe I can
provide a patch for this, too.
Although it's a nice performance increase, I think that breaking
count() as a method name is not a good idea, as I would assume it's
used a lot. Even though count() and strlen() can be optimised that much,
how much does it buy a fully fledged application?
I think it depends on the experience of the developers. There are many -
halfway ugly - PHP optimization tricks on the net. If these are used, the
difference wouldn't that much. But constructs like for($i=0; $istrlen($x);
$i++) could get optimized vigorous.
Then there is also the deliberation on whether it's good to go this
general direction, because I am sure we can make a case to convert every
function into an opcode perhaps.
This would make extension development much more complicated.
cheers,
Derick
grz Robert
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
[PHP-DEV] Changed behaviour for strtr()
Here is the next one. I think it's quite intuitive to use strtr() to remove single characters of a string, too, instead of using many str_replace($str, $chr, ). I'd glad to see this change also in 5.4. Additionally, I've removed the lookup-table generation as gcc doesn't optimize this away. Robert
[PHP-DEV] foreach() for strings
foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I think, adding features like this persuades the one or the other PHP user to upgrade to 5.4. Robert
Re: [PHP-DEV] foreach() for strings
2011/6/20 Derick Rethans der...@php.net On Mon, 20 Jun 2011, Robert Eisele wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. Yes, this sounds like a good addition to me. One question though, what to do with an object that implements __toString() ? That's the question, maybe one must force __toString() via an explicit string-cast: foreach( (string) $obj as $k=$v) We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I don't think we should do it for bits, as nothing in PHP really does do anything with that. If you want to do stuff with bits, I think the bitset package (http://pecl.php.net/package/Bitset) is the way forwards. yep, i totally agree. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
[PHP-DEV] Negative string offsets
Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; $str[0] == H $str[-1] == o; If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. The same thing for setting: $str[-1] = '0'; $str[-4] = 4; will result in H4ll0 Would be glad to see this in 5.4 Robert
Re: [PHP-DEV] PHP patches
Could I please get an wiki account? I've posted some stuff on the mailing list, but I think it would be better to document all this stuff on a central place, also with regard to get these things rated. Robert 2011/6/17 Lester Caine les...@lsces.co.uk Sebastian Bergmann wrote: [...] Hello Robert, welcome to this list. I think it would be best if you propose the patches individually instead of proposing one big patch. Especially with little nuggets like Deleted short open tags and ?php= is the new ?= Don't have time to go through everything else there so there may be others that are not acceptable. $_REQUEST certainly has a place in my code base ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/**index.phphttp://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: crypt
Developing PHP runtime -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
I would push this out in two steps. First: Negative string offset and later
range/slice
support for objects and strings. Objects would need a new magic method,
e.g. __slice(),strings need a substr() like interface. I think both are
accessed the
same way, but way are different. The slice support is furthermore much more
comprehensive and needs more testing and so on.
BTW: I can dimly remember that {} vs [] was already concluded in favor of []
for string access.
Robert
2011/6/20 Jordi Boggiano j.boggi...@seld.be
On 20.06.2011 14:02, Robert Eisele wrote:
Negative string offsets is a wish and also an implementation of my
running
PHP version for long. It operates in the same fashion like substr() with
negative offsets, but avoids the function call and is much smarter if one
single character has to be extracted:
$str = Hallo;
$str[0] == H
$str[-1] == o;
If -6 is used as offset, the old warning is displayed because it's the
first
undefined negative offset.
The same thing for setting:
$str[-1] = '0';
$str[-4] = 4;
will result in H4ll0
Would be glad to see this in 5.4
While this in itself is a good thing, I'd prefer to wait some more and
get a well thought-through, full fledged solution supporting ranges i.e.
$str[-1:2] or $str[-1,2].
I believe there were talks of such syntax a few years ago, maybe using
{} instead of []. I mean, right now both [] and {} seem to work equally
on strings and arrays, but changing {} to make it behave more like
substr/array_slice might be a viable BC break (for the negative numbers
that might exist in arrays that is).
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
I would not consider this for arrays and objects, too. If we had real
arrays, this would make sense but they are HT's and therewith it can also be
explained that -1 is an element and not the end of the chained list behind
the HT.
2011/6/20 Johannes Schlüter johan...@schlueters.de
On Mon, 2011-06-20 at 16:31 +0200, Etienne Kneuss wrote:
Negative string offsets is a wish and also an implementation of my
running
PHP version for long. It operates in the same fashion like substr()
with
negative offsets, but avoids the function call and is much smarter if
one
single character has to be extracted:
Do you mean ArrayObject? ArrayAccess is the interface.
Regardless, I don't believe it makes sense to change the semantics of
those indexes for arrays, since arrays can define negative indexes.
i.e. $a = array(-1 = foo, 2 = bar); $a[-1] should really be
foo, and not bar.
This clearly shows the inconsistency this brings. Maybe $var{$offset}
should be clearly deprecated for arrays and $var[$offset] for strings as
in PHP they work differently.
johannes
Re: [PHP-DEV] Negative string offsets
2011/6/20 Johannes Schlüter johan...@schlueters.de
On Mon, 2011-06-20 at 17:49 +0200, Robert Eisele wrote:
I would not consider this for arrays and objects, too. If we had real
arrays, this would make sense but they are HT's and therewith it can also
be
explained that -1 is an element and not the end of the chained list
behind
the HT.
Yes. So having this in the current form accepted means that
$a[-1];
can have two meanings:
1) Get the last item (byte in a string)
2) Get item `-1` (in an array)
Yes, sure. But if this feature is documented well, I can't see any
problems with this, especially if the trend goes towards a more
typed language where the user knows about the used data-type.
Which are to different things.
Currently we treat
$a{$o} and $a[$o]
as equal. My suggestion was to split this up to avoid the conflict from
above. I didn't suggest adding support for $a[-1] as last element for
arrays, I know quite well why this won't make sense.
I know about the equality of the two bracket forms. But I read somewhere
that
the trend goes towards [] - and maybe it was something from you.
johannes
2011/6/20 Johannes Schlüter johan...@schlueters.de
On Mon, 2011-06-20 at 16:31 +0200, Etienne Kneuss wrote:
Negative string offsets is a wish and also an implementation of my
running
PHP version for long. It operates in the same fashion like
substr()
with
negative offsets, but avoids the function call and is much smarter
if
one
single character has to be extracted:
Do you mean ArrayObject? ArrayAccess is the interface.
Regardless, I don't believe it makes sense to change the semantics of
those indexes for arrays, since arrays can define negative indexes.
i.e. $a = array(-1 = foo, 2 = bar); $a[-1] should really be
foo, and not bar.
This clearly shows the inconsistency this brings. Maybe $var{$offset}
should be clearly deprecated for arrays and $var[$offset] for strings
as
in PHP they work differently.
johannes
Re: [PHP-DEV] Negative string offsets
2011/6/20 Stas Malyshev smalys...@sugarcrm.com Hi! Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; Sounds OK, but what would happen if I do $str[-10] = '?'; ? As I wrote: If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. Would be glad to see this in 5.4 For that you'll need RFC with attached patch ready quite soon. I'll attach a patch in 2 days (still have to wait for the new power cable of my macbook) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] Changed behaviour for strtr()
Stas, Why should it be a BC break? Empty strings are not considered, in any mode or what feature of strtr() did I miss? Gustavo, does you not constradict yourself, when you say it's already available in the one mode and in the other it shouldn't be? What about the intuitive and nosy developers that expects this feature in both modes, the array-mode and the string-mode? And yes, it would be a third completely different algorithm. But every algorithm is specialized for one use-case, and I think we shouldn't decide such things based on the number of algorithms used; especially for such a basic function where the result should be calculated as fast as possible, no matter which algorithm led to the final result. You also call it a BC break, what did I missed? If we agree with this feature, we could, of course, search for a different syntax; but it was the most obvious. Robert 2011/6/20 Gustavo Lopes glo...@nebm.ist.utl.pt Em Mon, 20 Jun 2011 12:32:30 +0100, Robert Eisele rob...@xarg.org escreveu: $demise = strtr(passion, os, ); This is a very bad idea for several reasons: - strtr already does this with: $demise = strtr(passion, array(o = , s = )); - it's a BC break - adds a *third* operation mode to strtr, which (IMO unwisely) already provides two completely different algorithms. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP patches
Thanks, Johannes! :) It works. 2011/6/20 Johannes Schlüter johan...@schlueters.de On Mon, 2011-06-20 at 07:11 -0700, Philip Olson wrote: On Jun 20, 2011, at 7:01 AM, Robert Eisele wrote: Could I please get an wiki account? I've posted some stuff on the mailing list, but I think it would be better to document all this stuff on a central place, also with regard to get these things rated. Greetings Robert, Considering the number of patches you've already shown, I think applying for an SVN account would work better as it'd give you full wiki access. We can worry about karma (commit rights) later. He did and according to master.php.net the account was granted. Robert, you should be able to login using your svn data to the wiki. :-) johannes
Re: [PHP-DEV] Re: foreach() for strings
I really like the ideas shared here. It's a thing of consideration that
array-functions should also work with strings. Maybe this would be the way
to go, but I'm more excited about the OOP implementation of TextIterator and
ByteIterator, which solves the whole problem at once (and is easier to
implement, as mentioned by Stas). As Jonathan said, Database results with a
certain encoding could get iterated, too. The only way to workaround the
Text/Byte problem would be, offsetting EVERY string with 1-2 byte
string-type information or an additional type flag in the zval-strcuture.
Handling everything with zval's instead of objects would have the advantage,
that database-layers like mysqlnd could write the database-encoding directly
into the zval and the user had no need to decide what encoding is used.
A new casting operator (binary) could then cast the string to a 1-byte
array. But this is syntactical sugar over OOP-implementations - I don't know
which one is the better choice.
For example:
$utf8_string = Jägermeister; // information of utf8 ist stored in the zval
foreach ($utf8_string as $k = $v) // would iterate in byte mode
foreach ((binary)$utf8_string as $k = $v) // would iterate in text mode
over this:
$utf8_obj = new ByteIterator(Jägermeister);
foreach ($utf8_obj as $k = $v)
foreach ($utf8_obj-toText() as $k = $v)
I think the first one is easier and would be nicer to average developers
(and lazy programmers like me ;o) )
Todd, I don't like neither str_split() nor text_string_to_array(). Sure,
str_split could be optimized to return a different more optimized result
inside of foreach() but I would use rather one of the implementations,
mentioned above.
2011/6/20 Todd Ruth tr...@proposaltech.com
On Mon, 2011-06-20 at 10:06 -0700, Stas Malyshev wrote:
Hi!
On 6/20/11 9:57 AM, Todd Ruth wrote:
Iterators are nice. Having a text_string_to_array function
would also be fine. For example:
$s = 'hello';
foreach (text_string_to_array($s) as $x) {
var_dump($x);
}
text_to_array($s) == str_split($s, 1)
Does that have approximately the same performance as marking the
string as being OK to use as an array? For example,
$s = file_get_contents($big_file);
foreach (str_split($s, 1) as $x) {
f($x);
}
Are there performance issues with the above compared to:
$s = file_get_contents($big_file);
foreach (text_string_to_array($s) as $x) {
f($x);
}
assuming text_string_to_array could be implemented as marking
the string OK to use as an array.
Again, I don't know enough about the internals. I'm just imagining
a significant difference for very long strings between:
$a1 = text_to_array('hello');
and
$a2 = array('h','e','l','l','o');
$a1 and $a2 could act identically until a set occurred. For example,
$a1['key'] = 5; would first trigger $a1 becoming just like $a2 so
that the set could take place.
Any string that has not been hit with text_string_to_array would lead
to all the usual error messages some of us know and love and
any string that has been hit with text_string_to_array would allow all
the fancy features some people are seeking. I'm trying to find a
way to please the people that want strings to act like arrays without
ruining the day for those of us who are glad strings don't act like
arrays.
- Todd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP patches
Hi, my name is Robert Eisele. I'm new to this mailing list, but the one or the other might have seen something from me. I publish some open source stuff on my blog www.xarg.org, where I recently published my PHP fork, too. To avoid license bashing, it's not a fork at all and I don't want to manage something like this for myself, but rather a collection of patches + a proof of concept, with some new things and ideas that could get implemented into the main tree of PHP. There were some constructive discussions on hackernews and my blog, too: http://www.xarg.org/2011/06/php-hacking/ http://news.ycombinator.com/item?id=2640756 I didn't follow any discussion on PHP internals. It seems, many people understand and agree the changes I made. I've also realized that some changes are still proposed and maybe already implemented. I'd like to contribute these changes to PHP and maybe work a little more on the internals of PHP after that. Anyway, could you please help in finding a consensus for the changes? Could I get an wiki account to file all new changes for a vote, too? Thanks, Robert Eisele
Re: [PHP-DEV] PHP patches
Sebastian, Thanks for your welcome. I thought I split up the patch into smaller per-problem patches if I know what's new and what needs a patch for the RFC. Sorry for the newbe questions, but should I add a patch for every proposal; and if so, should I add it directly to the mail as attachement or as external reference? Should I add duplicates with a patch? I've seen, e.g., short array syntax and binary numbers like in C# and python are already on the list of features for PHP5.4. Is there a chance to get new features into PHP5.4 via vote? Many comments of the sites, I've mentioned, indicate that they would be glad to see some of these changes in 5.4 - myself included. Robert 2011/6/17 Sebastian Bergmann sebast...@php.net On 06/17/2011 09:58 AM, Robert Eisele wrote: [...] Hello Robert, welcome to this list. I think it would be best if you propose the patches individually instead of proposing one big patch. Best, Sebastian -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
