Re: [PHP-DEV] RFC: Increasing the default BCrypt cost
> On 09/07/2023 4:37 PM CDT Craig Francis wrote: > > We recently discussed hashing and costs at one of our OWASP meetings, we came > to conclusion that the default of 10 for bcrypt probably should be increased, > but only to 11 for typical websites. The main concern was about making > denial-of-service attacks easier (think of a normal website developer, who > won't limit the number of login attempts). > I fought long and hard to get bcrypt down from cost 12 to only cost 10 even though cost 9 was over powered vs the other settings. At the time cost "8.1" was equivalent to the other settings. After the recent settings increase of the others, cost "8.7" is equivalent. Currently all of the OWASP settings come directly from me except bcrypt. The only way I was able to get it down to cost 10 was giving equivalent settings to cost 12 for the other algorithms. Just to show that those numbers were obviously too high. Note that bcrypt cost 12 is currently as strong as PBKDF2-HMAC-SHA256 with ~6,000,000 iterations. Which is an insane number for web auth. Anyway I don't look forward to arguing with OWASP to keep bcrypt at cost 10. Even though it's currently 2.5x stronger than the other accepted settings. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost
> On 09/22/2023 2:04 AM CDT Nicolas Grekas wrote: > > > I was wondering if you considered also raising the Argon2 default cost? Has > this been discussed? > Argon2 defaults are actually quite high at a theoretical speed of ~1.3 kH/s/GPU (960,000,000,000/(64*1024^2)/(3*4-1) or in general bandwidth/(m*1024)/(3*t-1)). The actual speeds are likely half that or less because of GPU memory size being the limiting factor. Note "<10 kH/s/GPU" is considered good. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost
I know I'm late but bcrypt cost 12 (which looks like the winner) is high. Cost 12 is ~1 kH/s/GPU and the accepted limit for good settings is <10 kH/s/GPU. Cost 12 is 10x stronger than it needs to be as a *minimum*. I believe cost 10 is a good *default* for the next 1-3 years and cost 11 should be good for the next 5-10 years. There are two methods for picking settings: defender takes ≲100 ms and attacker gets <10 kH/s/GPU. Costs 9, 10, and 11 are the only ones that meet both limits (cost 11 for some defenders). Also the poll for increasing from cost 11 to cost 12 should be a 2/3 majority to get cost 12. Since the poll for increasing from cost 10 to cost 11 is a 2/3 majority. You can think of this as a 2/3 majority poll to increase to cost 11 followed by a 2/3 majority poll to increase to cost 12. > On 09/21/2023 12:26 PM CDT Tim Düsterhus wrote: > > > Hi > > I just opened the vote for the "Increasing the default BCrypt cost" RFC. > The RFC contains a two votes, one primary vote that requires a 2/3 > majority to pass and a secondary vote deciding on the new costs with a > simple majority. Voting runs 2 weeks until 2023-10-05 17:45 UTC. > > Please find the following resources for your references: > > RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023 > Discussion Thread: https://externals.io/message/121004 > Feedback by a Hashcat team member on Fediverse: > https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075 > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal to deprecate crypt()
If crypt() is removed, you can still use password_verify() to verify all the password hashes created by crypt(). The only thing you lose is creating those bad password hashes. Which can be done in userland because most people aren't changing their passwords daily. So it will run that slow userland code infrequently. This will not help the nested bcrypt example. Well besides the last bcrypt call can be password_verify(): password_verify(crypt($password, $hash), $hash); > On 02/21/2022 4:10 AM Tim Düsterhus wrote: > > > Hi Marco > > On 2/21/22 10:15, Marco Pivetta wrote: > >> If it's not going to be removed, what's the point of annoying people > >> with deprecation warnings (that they would patch out/silence anyway)? > >> > > > > Probably to be removed in `9.0` or `10.0`? Yes, it should be removed at > > some point. > > In contrast to other deprecations (e.g. the utf8_encode/decode currently > discussed), deprecating and ultimately removing crypt() results in an > actual loss of functionality. > > Even if we leave out that home-grown nested BCrypt hashing out of the > picture, crypt() allows one to interoperate with non-PHP-software that > does not support BCrypt, but supports the SHA-X variants. I already > mentioned Dovecot as an example, but BCrypt support in glibc in general > is something that was added only somewhat recently (and I'm not even > sure if that's only for Debian-based systems or generally available [1]). > > Yes, users should just use password_hash() if they need to hash > passwords. Yes, the documentation for crypt() should more prominently > point to password_hash() as the better alternative. But if crypt()'s > features are what you need, then alternatives to crypt() (e.g. a > userland implementation or FFI) certainly are going to be even worse. > > Best regards > Tim Düsterhus > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16814 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal to deprecate crypt()
> On 02/20/2022 1:10 AM Stanislav Malyshev wrote: > > > Hi! > > On 2/19/22 6:03 PM, st...@tobtu.com wrote: > > crypt() should be deprecate because it can be used to create bad password > > hashes: > > I don't think it's a good reason for deprecating functions. A lot of > functions, if used incorrectly, could produce bad results, it's not the > reason to not use them correctly. > Sorry, I really meant to say it can *only* create bad password hashes... and bcrypt which password_hash() is the preferred function to create a bcrypt hash. crypt() should be deprecated, unless there's a reason to let users write: $hash = crypt($password, "$2y$" . str_pad($cost, 2, "0", STR_PAD_LEFT) . strtr(base64_encode(random_bytes(16)), '+', '.')); // hi from 9 years ago https://www.php.net/manual/en/function.crypt.php#111086 (oof... ignore the minor errors and the update with random_bytes() because mcrypt was deprecated then removed) vs $hash = password_hash($password, PASSWORD_BCRYPT); Note the crypt() documentation: "password_hash() uses a strong hash, generates a strong salt, and applies proper rounds automatically. password_hash() is a simple crypt() wrapper and [password_verify() is] compatible with existing password hashes. Use of password_hash() is encouraged." That is the exact reason why mcrypt was deprecated: hard to use correctly and most uses of it were broken. Also ~99% of implementations of crypt() that use sha256crypt and/or sha512crypt password hashing algorithms are vulnerable to a long password DoS attack. Since they don't know they need to limit the password length because the runtime is O(pwLen^2+pwLen*rounds). Note a 14000 byte password takes ~1 second, 28000 is ~3 seconds, 56000 is ~11 seconds (results may vary depending on CPU and sha256crypt vs sha512crypt). Ignoring bcrypt: sha256crypt and sha512crypt are the only other algos that are not horrible and they are still very bad. > > Since password_verify() and password_needs_rehash() already supports hashes > > created with crypt(), the only thing needed to do is remove crypt(). > > Removing it would cause serious BC issues with no practical gain. What are "BC issues"?... Backward compatibility issues? If that's the case, you may not know that password_verify() can verify all password hashes created by crypt(). The whole point of deprecating and finally removing crypt() is that users can no longer create bad password hashes. This is a massive gain in security. It's like removing mcrypt which removed people's ability to ECB encrypt data. Sure there are very limited uses that are secure but 99.% are crypto101 errors. Also the *ONLY* non-broken password hash function that crypt() can do is bcrypt and password_hash()/password_verify() is a better alternative for bcrypt hashes. Basically crypt() serves no purpose besides as a legacy footgun. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal to deprecate crypt()
hash() is for cryptographic hashes and checksums. crypt() only supports password hashing algorithms which should not be used as a cryptographic hash or checksum because they are purposefully slow. > On 02/19/2022 7:16 PM Vasilii Shpilchin wrote: > > > Hashes are not for passwords only. For instance, hashes usually in use in > sharding and to calculate checksums. I suggest to add a warning to the > documentation, something like: if you need to hash a password, use > password_hash(). > > Best regards, > Vasilii. > > On Sat, Feb 19, 2022, 8:03 PM wrote: > > > crypt() should be deprecate because it can be used to create bad password > > hashes: > > > > * descrypt: 12 bits of salt is too small and it's ~100x faster to crack > > than md5crypt. Which itself is too fast for password crackers (see > > CVE-2012-3287). > > * Extended DES: 24 bits of salt is too small. > > * md5crypt is too fast for password crackers (see CVE-2012-3287). > > * sha256crypt and sha512crypt are dangerous (see CVE-2016-20013). > > > > Since password_verify() and password_needs_rehash() already supports > > hashes created with crypt(), the only thing needed to do is remove crypt(). > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RFC proposal to deprecate crypt()
crypt() should be deprecate because it can be used to create bad password hashes: * descrypt: 12 bits of salt is too small and it's ~100x faster to crack than md5crypt. Which itself is too fast for password crackers (see CVE-2012-3287). * Extended DES: 24 bits of salt is too small. * md5crypt is too fast for password crackers (see CVE-2012-3287). * sha256crypt and sha512crypt are dangerous (see CVE-2016-20013). Since password_verify() and password_needs_rehash() already supports hashes created with crypt(), the only thing needed to do is remove crypt(). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: New function: stream_socket_listen()
Hi, all -
Not sure why the domain @metrodigi.com is on this working group's list. I
did not sign up for it.
Since I have to put up with the email noise, I might as well get
something out of it so here goes:
We are a well funded, rapidly growing tech company working near San
Francisco that is looking for senior PHP developers. Awesome work
environment, super good salary and benefits and very cool cloud/mobile
growth market.
Check us out: http://www.metrodigi.com/jobs
HIRING 4-5 DEVELOPERS IMMEDIATELY.
Cheers,
Steve
Steven McKinney
*metrodigi | CEO*
tel: 415.578.2926 | cell: 415.806-8654 | fax: 415.785.3421 |
www.metrodigi.com
On Fri, Sep 6, 2013 at 6:03 AM, Daniel Lowrey rdlow...@gmail.com wrote:
This is a reasonable point. Personally I'd prefer to have as much socket
functionality as possible available natively without an extension. More
discussion is probably necessary on this point, though.
So what's the ultimate goal? Do we want to do try to move away from the
sockets extension? Or should we maintain the status quo (broad support for
standard use-cases with the extension there if you need more)? If it's the
latter I'm not sure `stream_socket_listen()` is actually necessary. If we
want to keep ext/sockets around for non-trivial use-cases then adding
one-off stream functions like this might only serve to muddy the waters and
create bloat.
Also ...
For instance, the API is likely to get messy if you start trying to
set arbitrary options on a socket before binding.
I'm not sure consistent cross-OS socket support will ever be anything but
messy (internally), which is a big part of why a uniform API would be
useful.
On Fri, Sep 6, 2013 at 8:47 AM, Chris Wright daveran...@php.net wrote:
I'm generally agreed with everything said below by everyone - but Wez's
message has
caused me to wonder whether it might be worth simply creating
stream_import_socket()
instead.
Yes, the sockets extension is not always available, but I would suggest
that
any
instance that needs something that streams cannot currently provide is
likely to be
an instance over which the developer has more control (anyone trying to
listen for
connections on shared hosting is going to run into more roadblocks than
just
a lack
of the sockets ext, for example).
Equally, it's nice to be able to treat a socket as a generic stream, and
I
wouldn't
want this functionality to disappear or become harder to use.
As it stands, there is currently quite a bit of duplicated functionality
-
I
think
that a line needs be drawn that defines which extension is responsible
for
what
i.e. leave the trivial stuff to streams and anything more advanced - I
saw
multicast being banded about below - to the sockets extension. For
instance,
the
API is likely to get messy if you start trying to set arbitrary options
on
a
socket before binding.
That said, I'm have no actual objection to Daniel's patch, and I too
would
like to
see a stream_socket_set_option() or similar.
My $0.02
Thanks, Chris
-Original Message-
From: Daniel Lowrey [mailto:rdlow...@gmail.com]
Sent: 06 September 2013 06:24
To: Wez Furlong
Cc: internals@lists.php.net; Sara Golemon
Subject: [PHP-DEV] Re: New function: stream_socket_listen()
Hi! I'm with you @Wez -- allowances for assigning common socket options
would be a major win. I'll see what I can do about working on something
more
robust than this one-off function PR.
On Friday, September 6, 2013, Wez Furlong wrote:
I'm not opposed to the idea; the reason that I didn't implement it
initially is that I wanted something functional in the core
(ext/sockets was often not available) and we didn't have PHP Spirit
equivalents of the various and murky socket option setting APIs that
are present in ext/sockets (it's not the most intuitive interface even
for
C developers).
So we got an implementation that does what you want for most cases;
bind and listen in one step.
I won't block this patch, but it would be /really/ great if you could
follow-on with a diff to allow setting the most commonly used socket
options (plus SO_REUSEPORT, since you mentioned it) and also a
function to allow setting CLOEXEC (perhaps stream_set_cloexec(bool)),
which is something I wish I'd added back when I put this stuff
together!
You win super extra crazy bonus points for allowing something like
this
https://bitbucket.org/wez/couchshare/src/bcbf02e1a70d0dba86564480c63f5
d6596658815/upnp-srv/couchshare.c?at=default
for setting multicast options.
Thanks!
--Wez.
On Thu, Sep 5, 2013 at 12:10 PM, Sara Golemon
poll...@php.netjavascript:_e({}, 'cvml', 'poll...@php.net');
wrote:
Seems reasonable to me, but Wez should probably weigh in on it. I
vaguely recall a conversation with him when he first implemented
stream_socket_
Re: [PHP-DEV] [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
On 4/8/13 11:28 PM, Laruence wrote: bug is described at #64554 - https://bugs.php.net/bug.php?id=64554 I proposal to add a leading backslash to all classnames (not only ns names, since no harm, consistent and make sense) when doing serialize, var_export etc. Short term: Add note to the var_export() docs: For full compatibility with namespaces, the representation must be executed within the root namespace. Proposal seems reasonable to me (as Johannes mentioned, serialize should already be OK). I think we're under no obligation to have serialized forms created in one version work in previous versions [1], though FC of already persisted strings are important. Note this won't solve the problem of existing var_export strings created in past versions. (We'll still need some kind of note.) [1] If an app needs BC of code like \Foo::__set_state(... I would think it'd be easy enough to strip away the escapes. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] more secure unserialize()
On 4/1/13 3:18 PM, Stas Malyshev wrote: Why? Making use of one parameter is orders of magnitude easier than refactoring your whole application to not use serialize() (especially if you need object support). Under the RFC, unserialize could potentially create __PHP_Incomplete_Class objects (including nested ones), so new handling code would be needed to care for these cases and I wouldn't describe that as a simple fix depending on how the app wants to deal with these cases. IMO these projects would be better off creating drop-in replacements for (un)serialize that wrap in HMAC to secure the data channel. Trivially done in userland. The next best thing would be an unserialize that would simply fail if a non-whitelisted class was found. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] more secure unserialize()
I think this RFC would worsen the problem of misusing the serialize round-trip. Even if we make the docs clearer, we'd still be sending the message that there's a new safer unserialize and some would certainly use that new feature to be more lax about guarding serialized structures. It also sets up a situation where altering either the whitelist or one of the classes in the whitelist could open a vulnerability that's not obvious. I'm also not convinced that this feature would spur developers to fix insecure code. But setting my arguments against, if the goal is to make unserialize() secure, then it should behave like a tripwire: fail loudly if a non-whitelisted class object is found. I think returning partially-usable values would gives devs more rope to hang themselves with. Re the 2nd arg, I'd make only two cases: * null is given: default behavior * non-null given: cast to array and that's the class whitelist. If the overall goal is to make the serialize/unserialize round-trip tamper-proof, we could build HMAC right into the API: add secret key args to both functions. No doubt the Suoshin patch already uses HMAC during encryption of the session data. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTimeImmutable
On 3/26/13 3:29 PM, Michael Wallner wrote: I am concerned by the introduction of DateTimeImmutable extending DateTime ... If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. ... In my opinion, the only way to solve this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. Much agreed. DateTimeImmutable is welcomed as a better design, but it is not a clean substitute for a DataTime object. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Could we kill call_user_func?
On 3/21/13 7:37 AM, Derick Rethans wrote: On Fri, 15 Mar 2013, Steve Clay wrote: call_user_func() just seems so ugly now that we have nicer syntax in so many other areas. That doesn't mean we should just be ripping out functionality that works perfectly fine. I was not clear in my initial post. I don't want call_user_func removed, just made unnecessary. To reiterate why: 1. call_user_func fails reference args. (It's not a full substitute for a direct call) 2. Most callable values are already directly callable: ✓ func as string ✓ dynamic method as array ✓ static method as array static method as string ✓ Closure ✓ object with __invoke Closure in object property (I understand why this is off the table) expression containing Closure in object property If always store the callable in a var, the situation is much better: ✓ func as string ✓ dynamic method as array ✓ static method as array static method as string ✓ Closure ✓ object with __invoke ✓ Closure in object property How difficult would it be to support making this work? $c = Foo::bar; $c(); Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Could we kill call_user_func?
I'm sure this question has been discussed before, so if anyone can point to me to links or briefly recap I'd appreciate it. Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq I understand the problem of $obj-foo() where -foo is a callable property. The workaround could be: ($obj-foo)(); call_user_func() just seems so ugly now that we have nicer syntax in so many other areas. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Allow all callables to be called directly
My subject was misleading. I didn't mean to suggest call_user_func() be removed, just be made unnecessary by direct call syntax. This should make the inconsistency clearer: http://3v4l.org/L8Yvq On 3/15/13 10:21 AM, Sebastian Krebs wrote: You don't need to use it, if you don't like it. I do need to use in case my $callable is an object callback. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow all callables to be called directly
On 3/15/13 11:11 AM, Nikita Popov wrote: I don't know why 'class::method' isn't supported, but I guess it's just a legacy syntax that was superseded by the array notation 'class::method' was added significantly *later*, so I think it's fair for devs to assume that it would be supported like other callables... Anyway, file under Would Be Nice Someday. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] feature request : easy shared memory
On 3/14/13 10:31 AM, rene7705 wrote: (ideally I would like to get a pointer) PHP's environment is torn down after every request, so no matter what the mechanism you generally can't store anything that can't be serialized. See also https://www.google.com/search?q=php+shared+memory Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static type-references
On 3/14/13 12:26 PM, Rasmus Schultz wrote:
Hey List,
What do you think about adding a typeof() operator to PHP?
gettype(), get_class().
If you wanted gettype() to return a classname instead of object, then you'd have to add
reserved words for all the native types. Otherwise:
class string {}
gettype(new string);
???
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static type-references
On 3/14/13 12:26 PM, Rasmus Schultz wrote: $user_type = typeof(User); I missed this. We'll soon have User::class. This may resolve to, e.g., 'Foo\User'. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed changes to PHP language
On 3/6/13 7:48 AM, Max Romanovsky wrote: 2. Introduce base class for all PHP classes. E.g. Object. It would help in type hinting and allow to add new common methods without any magic. Type-hinting for non-stdClass objects would be handy. Base class is like mutable Object.prototype in JS. I'm against it. 3. Parse body of PUT request in the same manner as it's done for POST There are arguments for/against here: https://bugs.php.net/bug.php?id=55815 compatibility. Otherwise $_REQUEST handling should be aware of new array with PUT data. For BC, PUT data should not be injected into existing vars. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
On 3/6/13 4:10 PM, Bob Weinand wrote: https://wiki.php.net/rfc/unset_bool What's the return value of unset($setValue, $undefined) ? Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting separate outputs with Date Functions
On Wed, Feb 20, 2013 at 1:54 PM, David Soria Parra d...@php.net wrote: I ran into this myself and I personally consider date() assuming your configured TZ A bug. The description for date() says local time/date = considering TZ is not a bug. Timestamps are defined as UTC and the behaviour of DateTime is correct there, that it always assume UTC. date() should do the same. I rather think DateTime::__construct/date_create were wrongly designed for ignoring the second parameter. Timestamps specify a uniform reference of time, but just because you use them doesn't imply you're sitting in any particular TZ. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
Setting aside difficulty of implementation, I'm coming around to the idea, though I think you could simplify it by cordoning off an entire namespace. E.g.: A namespace at least two deep (e.g. \A\B\) may be marked 'protected' (by some method TBD). Classes and functions declared in a protected namespace can only be accessed from methods or functions inside the same namespace, or in ancestor namespaces. E.g., if \Foo\Internal\ is protected, access of its classes/functions must originate from classes/functions defined in \Foo\, \Foo\Internal\, or \Foo\Internal\*. This would allow something like nested classes, but obviously with a lot more flexibility. In practice, plugin code sitting in, say, \MyPlugin\ could freely access \Framework\SomeClass, but not \Framework\Internal\SomeClass. I see some value there, but there's tons of questions remaining and how to to implement the damn thing... Steve Clay -- http://www.mrclay.org/ On 2/28/13 1:56 AM, Jens Riisom Schultz wrote: * In response to the argument that php has no assembly concept: I know this, but namespaces are as close as we get, and would effectively solve this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
On 2/27/13 3:18 AM, Nikita Nefedov wrote: I, for one, think it should be solved on the IDE side. I used a lot of Doctrine's internal methods lately and if they would be not accessible I wouldn't be able to do a lot of things. Of course internal methods/classes shouldn't be exposed as a part of API, but if they exist, I would want to call them *if I know what I'm doing*. I think it would be useful if phpdoc had an @internal tag so that IDEs could highlight places where you use internal parts of library. Agreed, IDE/phpDoc is the place for a solution (and I do recognize that there is some need here). phpDoc already supports @access private for items to be left out of public documentation. An IDE could be configured to have these items appear greyed or not to appear in autocomplete lists. There's already a way to tightly control access: embrace OOP and eliminate statically accessible APIs (global vars/funcs and static props/methods) that you don't want people calling. You don't actually need them. Although closures helped too, PHP gained true information hiding in 5.0 with private. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
On 2/27/13 10:22 AM, Sebastian Krebs wrote: 2013/2/27 Steve Clay st...@mrclay.org phpDoc already supports @access private for items to be left out of public documentation. An IDE could be configured to have these items appear greyed or not to appear in autocomplete lists. a) You misuse the private visibility here: @access private comes from old PHP4-days, where the DocComment must know the visibility, because the method itself didn't Sure, but phpDocumentor1 currently uses @access to control documentation output (the description doesn't mention access/visibility at all and protected does nothing). http://manual.phpdoc.org/HTMLSmartyConverter/default/phpDocumentor/tutorial_tags.access.pkg.html For phpDoc2 the OP should also check out these: http://www.phpdoc.org/docs/latest/for-users/phpdoc/tags/internal.html http://www.phpdoc.org/docs/latest/for-users/phpdoc/tags/api.html http://www.phpdoc.org/docs/latest/for-users/phpdoc/tags/ignore.html Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Travis-CI supports 5.5 (was: Voting periods)
On 1/29/13 11:55 AM, Larry Garfield wrote: [3] We have a CI system in place but it's home grown, doesn't have enough human resources maintaining it, and I don't think it supports multiple variants of the PHP environment Dunno if this was mentioned here, but Travis CI added a 5.5 environment a few weeks ago. Spreading the word to projects to add 5.5 to their config files (or just sending a PR) would be a quick way to get a lot of code hitting 5.5. E.g. https://github.com/symfony/symfony/blob/master/.travis.yml @todo https://github.com/zendframework/zf2/blob/master/.travis.yml https://github.com/cakephp/cakephp/blob/master/.travis.yml https://github.com/auraphp/Aura.Web/blob/develop/.travis.yml https://github.com/EllisLab/CodeIgniter/blob/develop/.travis.yml https://github.com/laravel/laravel/blob/master/.travis.yml ... Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Travis-CI supports 5.5
On 1/29/13 2:17 PM, Jordi Boggiano wrote: Travis is still running 5.5.0-alpha1 that segfaults under some conditions when using composer which makes a lot of builds fails for nothing. How Symfony deals with this: matrix: allow_failures: - php: 5.5 Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Thoughts on scalar objects
Re: https://github.com/nikic/scalar_objects Initial impression: This patch reminds me of extending native prototypes in Javascript, with similar limitations that may explain why this has fallen out of fashion in JS. The big one is that allowing change to the prototypes introduces global state with all the problems that implies. The second is that you can't store local state beside the value. E.g. a useful UTF-8 string class would want to store some extra state like: has the string been validated, and are all chars in ASCII. Other ideas: * Instead of registering a single class to wrap a native type, allow users to register handlers that receive the native value, the type, the called method name, and args. This allows altering behavior based on the value/method at call-time. The handler would return a 2 member array: the first would indicate whether the handler actually handled the call, the second would have the return value. * Would it be possible to limit this behavior to a particular scope? Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] C# properties vs. accessors RFC
First of all, I think the functionality provided by Clint and Nikita's RFC [1] is in
demand and would be an asset to PHP, but I also think it can repackaged more simply.
People are comparing the RFC to C# [2], but while they look similar, C# has a simpler
implementation we should learn from.
1. C# draws a firm line between property and field, keeping both concepts
simple.
A field is like a PHP property. There's no more to understand.
A property is simply a set of functions emulating a field, and $value is available in
the setter body. There's no more to understand.
Importantly, I think, the property takes the place of a field; there's never a shadow
field of the same name to think about. The obvious downside is you must use a
distinctly-named field for storage, but the upside is conceptual and behavioral
simplicity. There's no need for guarding mechanisms and rules about where $this-prop
will mean field access or trigger getter/setter; we know there is no field prop, period.
As Sharif Ramadan pointed out, it also makes state snapshots clearer as there is no value
stored under prop to potentially confuse. Under the RFC, every property would show up as
a field *even if the accessors didn't use that field*.
2. C# has no issetter/unsetter.
IMO customizing these functions is completely unneeded for the vast majority of use cases
and could be replaced by simpler logic: isset($this-prop) calls the getter and compares
to NULL; unset($this-prop) passes NULL to the setter.
3. C# has no auto-implementations.
IMO auto implementations have some value removing boilerplate, but we should not make them
violate #1. We could have the property syntax specify what field to use for underlying
storage, or simply conclude that the boilerplate is worth the clarity.
I think the path forward is to determine how we can serve the same goals as this RFC, but
retain the conceptual simplicity of the C# implementation and maybe syntax that strays
less from current PHP.
I have some ideas that I could start forging into an RFC. Consider this:
class Foo {
private $_bar;
public function get bar { return $this-_bar; }
public function set bar { $this-_bar = $value; }
}
Advantages I see over the RFC:
* It's clearer that the accessors map to regular methods, and you know how to control
visibility of methods and how they're inherited.
* It's clearer $bar doesn't exist as a property, and it will never show up in state
inspection.
* You know $_bar is a plain PHP property, and you can initialize it directly in the
constructor; we don't need an initter.
* There are no guards/proxies/shadow property to think about
As for type-hinting, I think that could be achieved by a separate, simpler mechanism:
type-hinting the properties.
class Foo {
private Bar? $_bar;
}
$_bar is a regular property, but which can only be set to a Bar or to null (? implies
nullable). That gives you simple typed properties (useful and simpler to understand
without accessors), but also suggests how to combine these to get typed accessors:
class Foo {
// settable anywhere
public Bar $bar;
// read only
protected Baz? $_baz;
public function get baz { return $this-_baz; }
}
Down the road we could further address how to shorten this syntax but while keeping it
clear that accessors are just functions and properties are just value stores.
[1] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
[2] http://msdn.microsoft.com/en-us/library/x9fsa0sw(v=vs.80).aspx
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 1/17/13 1:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for inclusion in
5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to make this
happen for
5.5, voting and the specifications are here:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good implementation, and as long as authors use
accessors that depend on a separate property for storage (like other langs require),
everything will be straightforward. Otherwise, I fear they're in for some confusing behavior.
Consider the code from the RFC:
class TimePeriod {
public $Hours {
get { return $this-Hours ?: not specified; }
set { $this-Hours = $value; }
}
}
$tp = new TimePeriod();
$tp-Hours; // not specified
isset($tp-Hours); // true!?
The auto implementation of isset compares $this-Hours to NULL, but since $this-Hours
goes through the getter, it will return not specified. So the property will always
appear to be isset.
* The guards seem spooky: A set of tokens ($this-prop) will have varying behavior (e.g.
direct prop read vs. getter call) *depending on the call stack*.
* Giving issetter/unsetter no direct access to the property limits functionality and leads
to weirdness like the example above.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FW: Functionality request/proposal
On 1/14/13 9:53 PM, Paulo Henrique Torrens wrote: lots of code where people put it there, and I always get a little frustrated when using PHP because I'm used on adding it (without even noticing), and my code keeps failing Pay more attention and/or use an IDE that has templates and shows parse errors. Enforcing syntax is a good thing; Javascript's auto semicolon insertion has led to a staggering amount of wasted energy in bug fixing, understanding the feature, arguments about it, and altering code between the two styles. It was a terrible, terrible idea. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Why we must have parent property access at all? What's the use case and how do
other langs do it?
Am I right to say there is no parent property, this would just call the
parent's [gs]etter using the same underlying property value?
Steve
--
http://www.mrclay.org/
On Jan 10, 2013, at 6:15 PM, Nikita Popov nikita@gmail.com wrote:
On Sat, Jan 5, 2013 at 4:25 AM, Clint Priest cpri...@zerocue.com wrote:
Agreed. Some people may actually be using $parent as a variable name, not
difficult to imagine.
So far parent-foo seems to be the answer.
-Clint
My thoughts on the parent situations, as I'm not yet satisfied with the
current solution.
1) I tried to understand how the engine currently compiles and executes
object property fetches. I found it to be incredibly complex and I
certainly don't have the abilities to port this for statics. As such the
parent::$foo syntax is dead unless someone else is going to do the
necessary engine changes.
2) I think the parent-foo syntax is nice in concept, but I think that
it's an absolute no-go as it doesn't fit in with the rest of PHP (and would
still require some engine changes those complexity I can't really
estimate). The parent-foo syntax is some off mix between parent::$foo
(which makes sense) and $parent-foo (which also makes sense). parent-foo
combines it in an odd way that doesn't look like PHP and adds yet another
new syntax for something that's going to be a rare case anyway.
3) My suggestion is to avoid the engine and syntax related issues of parent
property access by putting this as a function in the standard library
instead. What I'm thinking about is a function like get_parent_property()
which returns the ReflectionProperty for it. Then you could do something
like this:
public $foo {
get { return 'parent is: ' .
get_parent_property('foo')-getValue(); }
set($val) { get_parent_property('foo')-setValue($val . '
something'); }
}
I know that this is not an optimal solution, but I would much prefer this
over some new syntax like parent-foo. Once (if) static properties have
better engine support we can switch to the cleaner parent::$foo way. But
until then I think that this is a good compromise, especially considering
that accessing the parent property shouldn't be a very common operation, so
it's okay if it's a bit more verbose.
This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could not
return a ReflectionProperty and instead provide two functions
get_parent_property and set_parent_property (what about isset and unset in
that case though?)
So, what do you think about this?
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On 1/8/13 2:56 AM, Christian Stoller wrote: But the way 'nullable' properties are defined is not very intuitive and unclean, in my opinion. Stas has already mentioned that. `public DateTime $date = NULL;` // this looks like the property is initialized with null, but it does not show that the property is 'nullable' Much agreed. After instantiation, these shouldn't behave differently: public $foo = null; public Foo $foo = null; Sure, method signatures have special behavior based on a default value, but IMO: 1. those semantics aren't entirely intuitive to begin with 2. property initializers aren't method sigs 3. the semantics would apply only to some properties public DateTime? $date; In C# the question mark after a type is a short hand for a generic Nullable type. I like that it's an established practice of doing exactly what we're trying to do. Could we not just make it obvious?: public Foo|null $foo; Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/13 5:43 PM, Stas Malyshev wrote:
The whole problem here is that the only reason why it is a problem is
because of the accessors that have hidden state in guards. If it were
regular variables (and for all the API consumer knows, they are) there
Please ignore this if it's been debated before:
AFAICT C# strictly separates fields (properties in PHP) and properties (a set of
accessors that emulate a field).
So the RFC provides 3 features (using C# terms):
1. A property API
2. A built-in storage variable so you don't need a separate field
3. Access to the storage variable as if it were a field of the same name
I think #2 is useful, avoiding the need to make a separate field just to make properties
read-only or type-hinted. However I think the complexity and confusion we're running into
is mostly caused by #3.
I think we might be better served by having another way to access this storage
variable.
What if instead, we have the storage var available as $prop inside all the accessors?
These would be the default implementations:
get { return $prop; }
set($value) { $prop = $value; }
isset { return $prop !== NULL; }
unset { $prop = NULL; }
Pros:
* Makes clear that $prop is regular var access, and that $this-PropertyName *always* goes
through accessors
* Gives isset/unset full access to the storage var, which allows doing things that can't
be done via setter/getter. E.g. you could actually implement a property being unset,
which would be different from having it set to NULL.
Cons:
* Allows evil, like having reads affect the storage var.
* Allows authors to hang themselves with recursive accessor calls, BUT those mistakes
would be apparent from looking at the code.
What functionality possible in the RFC would be lost by this?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/5/13 2:05 PM, Clint Priest wrote:
I like the alternate idea here, but I'm not sure what advantage it has over the
current
situation?
See the Pros I listed. The primary being a clear differentiation between calling
accessors and handling of the storage value associated with the property.
if an accessor is
already in the call chain then it will not be called again and standard property
rules
take effect.
I see that as not simpler, and in fact leading to small bugs whenever getters/setters
start becoming complex enough to call outside methods. Consider this:
class Foo {
public $bar = 2 {
get { return $this-calcBar(); }
}
public function calcBar() {
return $this-bar * 3;
}
}
echo $foo-bar; // 6
Within calcBar, $this-bar is the raw property (2), because hidden state has unwrapped
(if you will) the property.
echo $foo-calcBar(); // 18
But here, within the first call of calcBar $this-bar triggers the getter. Now, of
course, this is a foolish implementation, but within any method that could be called from
the getter/setter, the symbol $this-bar could mean two completely different things; I
think this is bad.
If, as I proposed, the storage var were only accessible as $prop in the accessor scopes,
that would force authors to pass $prop to any supporting methods, clarifying intent.
$this-bar would *always* be accessor calls.
In this model, I think infinite-loop-causing recursions would be easier to spot. If
absolutely necessary we could always throw a fatal error whenever a getter was called
twice in the same call chain.
Steve
AFAICT C# strictly separates fields (properties in PHP) and properties (a set
of
accessors that emulate a field).
So the RFC provides 3 features (using C# terms):
1. A property API
2. A built-in storage variable so you don't need a separate field
3. Access to the storage variable as if it were a field of the same name
I think #2 is useful, avoiding the need to make a separate field just to make
properties
read-only or type-hinted. However I think the complexity and confusion we're
running
into is mostly caused by #3.
I think we might be better served by having another way to access this storage
variable.
What if instead, we have the storage var available as $prop inside all the
accessors?
These would be the default implementations:
get { return $prop; }
set($value) { $prop = $value; }
isset { return $prop !== NULL; }
unset { $prop = NULL; }
Pros:
* Makes clear that $prop is regular var access, and that $this-PropertyName
*always*
goes through accessors
* Gives isset/unset full access to the storage var, which allows doing things
that can't
be done via setter/getter. E.g. you could actually implement a property being
unset,
which would be different from having it set to NULL.
Cons:
* Allows evil, like having reads affect the storage var.
* Allows authors to hang themselves with recursive accessor calls, BUT those
mistakes
would be apparent from looking at the code.
What functionality possible in the RFC would be lost by this?
Steve Clay
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On 1/4/13 9:41 AM, Nikita Popov wrote: https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax I like the proposal so far. I'm still a little hesitant about syntax for allowing the setting of NULL values. Since properties are NULL by default (I wish this were explicit in the docs), these are _completely equivalent_: public $f; public $f = null; So it bothers me that these would result in different behavior: public Foo $f; public Foo $f = null; Now, all properties with an object type must be NULL initially, so really we're deciding whether a property can be set *back* to NULL (outside the setter). We could just make the most common case the default behavior. Otherwise the author must provide the signature of the setter with/without = null. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On 1/5/13 7:25 PM, Anthony Ferrara wrote:
No, the other initializer that would be useful is `new Foo`. Assigning a
default value is not an initializer. An initializer is something that's run
on object construction (and has been discussed in other threads):
class Foo {
public DateTime $bar {
init: { $bar = new DateTime(); }
}
}
I think property init() would enable two bad practices:
1. putting too much logic in a property (SRP)
2. building dependencies within the object instead of injecting them (the better way is
what we already do: receive dependencies in the constructor and assign them to the properties)
null pointers. And if you set the property in the constructor (and it's
typed), you should never have the chance for it to be non-null, unless you
explicitly define it that way. Otherwise, you'd have to litter your code
with is_null checks... Which defeats the point of the syntax in the first
Which is why I think the default setting signature should not have = null. If someone
wants to allow setting the property *back* to null, they could easily:
public Foo $foo {
get;
set($value = null);
}
I agree with you that, in an ideal world, a property with a declared type would *never not
have* that type, but I think a property init() would be a bad tradeoff to make that a reality.
The class constructor is the best place to do this, and maybe this is why C# forces
property storage to be in fields; you can set fields directly from the constructor without
going through property setters.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Would the following two be exactly functionally equivalent?
public Foo $foo;
public $foo {
get;
set(Foo $value) { $this-foo = $value; }
}
We should also consider how an author would allow type-hinted properties to
accept NULL as a new value, in both proposals.
Steve
--
http://www.mrclay.org/
On Jan 4, 2013, at 9:41 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I already brought this up before, but I think the discussion at that time
was not very constructive and largely off-topic, so I'm bringing it up
again. To make sure everything is clear I wrote an RFC document:
https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax
This RFC proposes an alternative syntax for typehinting accessors, which
will in particular also allow to typehint properties directly, even if no
accessors are used (public DateTime $date).
What are your opinions on this?
Thanks,
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
private $date {
get;
set(DateTime $x) { $this-date = $x; $this-timestamp =
$x-getTimestamp();
}
private $timestamp {
get;
set($t) { $t = (int)$t; $this-timestamp = $t; $this-date = new
DateTime(@$t); }
}
}
What happens to it? Would it get into infinite loop or will just set the
value twice? What would be the correct way to write such a code (note
I think infinite recursion is a potential issue for lots of logging setups (let's log
when someone calls the logger!) and situations where you have multiple values to keep in
sync. The accessor implementation shouldn't try to solve these design problems.
class UserContext {
protected $user;
public $logger;
public $username {
get() { $this-logger-log(Getting username); return
$user-name; }
set($n) { $this-user = User::get_by_name($n); }
}
}
class Logger {
protected $ctx;
public function __construct(UserContext $ctx) {
$this-ctx = $ctx;
$this-logfile = fopen(/tmp/log, a+);
}
public function log($message) {
fwrite($this-logfile, [$this-ctx-username] $message\n);
}
}
$u = new UserContext();
$u-logger = new Logger($u);
$u-username = johndoe;
echo $u-username;
What would happen with this code? Will the log be able to log the actual
user name, and if not, how you protect from such thing? $username is a
part of public API of UserContext, so whoever is writing Logger has
right to use it. On the other hand, whoever is using logger-log in
UserContext has absolutely no way to know that Logger is using
ctx-username internally, as these components can change completely
independently and don't know anything about each other besides public APIs.
What I am getting at here is that shadowing seems to create very tricky
hidden state that can lead to very bad error situations when using
public APIs without knowledge of internal implementation.
Again, the problem is not shadowing (not even in use here) but really general information
hiding. You can create these problems anytime you have hidden information and
interdependent objects, and it's an API design problem.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/13 5:58 AM, Clint Priest wrote:
class Foo {
public $bar = 2 {
get;
set;
}
}
Consider properties not based on shadowed values:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
Here, initializing the shadow property is useless. It's similar to the case where you want
to have the initial value of a traditional property be the result of an expression (and
you can't because it would create a chicken-egg problem during construction).
Option 1: The most powerful solution I see is to have an init function that's implicitly
called before first access (and with direct write access to the shadow property if
needed). Consider trying to emulate the crazy document.cookie API:
class Document {
private $cookieProps;
public $cookie {
get { return /* based on cookieProps */; }
set { /* set some cookieProps */ }
// called implicitly before the first access (not before the
constructor runs)
// and would have direct access to the shadow property.
init { /* set up cookieProps */ }
}
}
Pros: can run any code necessary to initialize the property
Cons: must make a function just to have a default
Option 2: Keep the traditional syntax, but instead of always setting the shadow property,
call the setter with the given initial value directly before the first access.
Pros: familiar syntax; more expected behavior in some cases
Cons: what if there's no setter?; cannot run arbitrary setup code; setter can't
distinguish between a user set and the implicitly set before first access.
Option 3: A mix of both. The shadow property is always initialized with the value from the
traditional syntax. If needed, you can have an init that's called before first access.
Pros: For simple shadowed properties, just works as you'd expect and with familiar syntax;
Still allows robust initialization before first access if needed.
Cons: Author must remember that traditional syntax only useful for shadow prop.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zip stream looping issue
Before I look into this further, can someone confirm that fopen on a zip
stream should return something other than a null?
I've a zip called test.zip which contains 5 files,
a.txt,b.txt,c.txt,d.txt and yes, e.txt
The zip is valid and can be unzipped using unzip on linux.
Running the following code returns a null for each of the pointers reads
the first and 2nd files and finally loops somewhere in the fgets code at
100% cpu at the end of b.txt:-
$names=array('a.txt',
'b.txt',
'c.txt',
'd.txt',
'e.txt');
foreach($names as $name)
{
$fp=fopen('zip:///tmp/test.zip#'.$name,'r');
echo $name.':'.var_export($fp).\n;
while(!feof($fp))
{
$r=fgets($fp);
echo '.';
};
fclose($fp);
};
The information contained in this email is intended for the personal and
confidential use
of the addressee only. It may also be privileged information. If you are not
the intended
recipient then you are hereby notified that you have received this document in
error and
that any review, distribution or copying of this document is strictly
prohibited. If you have
received this communication in error, please notify Brendata immediately on:
+44 (0)1268 466100, or email 'techni...@brendata.co.uk'
Brendata (UK) Ltd
Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK
Registered Office as above. Registered in England No. 2764339
See our current vacancies at www.brendata.co.uk
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/13 11:41 AM, Clint Priest wrote:
class Foo {
private $realbar;
public $bar = 2 {
get { return $this-realbar; }
set { $this-realbar = $value; }
}
}
What would be the point of this?
I think it would be more readable for someone using the class. As a user it helps to know
the default of the property I'll actually be interacting with. In a non-trivial getter the
default may be much harder to tease out.
But yes, I agree that it's straightforward enough for the class author to set defaults as
needed, so I see no problem moving forward. The RFC should make clear that only the shadow
value is set (a setter, if present, is not used).
In the features docs I suggest finding a term for a non-traditional property, like
guarded property.
Also I think you should eliminate all shadowing language. IMO it adds more confusion
than it removes. Here's some language that may/may not be useful:
Almost all interaction with a guarded property is proxied, meaning the getter and setter
methods are used instead of direct reading/writing of the value. There are only two
exceptions:
1. Within a getter's scope, reads are not proxied: the property is read
directly.
2. Within a setter's scope, writes are not proxied; the property is written to
directly.
Accessors are free to interact with other properties which are visible to them, but access
to other guarded properties is always proxied.
Accessors are not required to use the property value, but it always exists.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/3/13 12:42 PM, Michael Wallner wrote: On 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote: I like the idea of an init function, but that would have to wait for a further release I think, or delay this whole project a year. We have constructors, shouldn't those be sufficient for that task? My initial view was that property inits would encourage encapsulation of property setup logic, and make sure the property was ready before access in the constructor. Basically the same reasons we allow initializing regular properties now. But now I think it would embolden authors to make overly complex properties (like document.cookie) that should really be separate objects. Lets not do that. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 6:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 A few remaining questions. The RFC makes it clear that ReflectionClass::getMethods() does not return internal method names like __setSeconds. 1. Are these names visible via get_class_methods() / method_exists() / is_callable()? 2. Inside an accessor, what do __FUNCTION__ and __METHOD__ evaluate as? 3. What happens if a class/subclass contains a regular method __setSeconds? Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 6:36 AM, Clint Priest wrote: Here is the updated RFC incorporating the feedback from previous rounds of discussion. https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 The RFC does not specify whether it's a fatal error to define a class (directly or via extends/traits) which has both a traditional property and accessor with the same name, but I think this should be prohibited to avoid confusion. One might expect this to work if the traditional property is private in a parent class, but I think even if the patch allowed that special case (I've not tried it), it should not. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 4:18 PM, Clint Priest wrote:
Omitting isset/unset has the same effect as declaring it without a body. This
is
described in the RFC under Automatic Implementations with this line:
Note that isset/unset implementations will always be provided if they are not
defined or
if they are explicitly auto-defined (as above).
I think the RFC could make this clearer: isset unset are always provided with the
default implementations unless the author provides his/her own.
Looking closer at the default implementations of isset/unset, I'm worried these could lead
to confusion. Consider this code:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
}
}
The RFC's default implementation is always bound to the shadow property, so here's what
you really get:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
// auto-generated
isset { return $this-Hours != NULL; }
unset { $this-Hours = NULL; }
}
}
Note the resulting behavior:
$t = new TimePeriod;
$t-Hours; // 1
isset($t-Hours); // false !?
unset($t-Hours);
$t-Hours; // still 1
Effectively, authors who don't base their getters/setters on the shadowed property must be
urged to create their own isset/unset because the default ones would be useless. I'm not
crazy about this.
I'd prefer these default implementations:
isset { return $this-__getHours() != NULL; }
unset { $this-__setHours(NULL); }
$t = new TimePeriod;
$t-Hours; // 1
isset($t-Hours); // true
unset($t-Hours);
$t-Hours; // null
isset($t-Hours); // false
Note these also work as expected when using the default get/set implementations. Of,
course, my implementations don't actually *work* because you can't call an accessor from
an accessor...
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 1/2/13 6:08 PM, Clint Priest wrote:
Sorry, there was a typo in that RFC there, this line:
isset { return $this-Hours != NULL; }
Should have been with !==:
isset { return $this-Hours !== NULL; }
I've already updated the 1.2 doc to reflect the correct way.
Given what I mentioned above, I'm assuming you did not test this with the fork,
right?
Just based your comments on how it should logically work (with the incorrect !=
vs !==?)
I haven't tested the fork. I just borrowed your logic with the typo :)
One last thing about that, the isset/unset with $this-Hours calls the getter
to retrieve
the $this-Hours value, so it behaves as your example below indicates.
The RFC says, only the accessors themselves may directly access the shadowed property. I
read that as:
Within get, $this-Hours is the raw shadowed property.
Within set, $this-Hours is the raw shadowed property.
Within isset, $this-Hours is the raw shadowed property.
Within unset, $this-Hours is the raw shadowed property.
But you seem to imply:
Within get, $this-Hours is the raw shadowed property.
Within set, $this-Hours is the raw shadowed property.
Within isset, $this-Hours is accessed via __getHours()/__setHours().
Within unset, $this-Hours is accessed via __getHours()/__setHours().
So really the default implementations behave like this:
isset { return $this-__getHours() !== NULL; }
unset { $this-__setHours(NULL); }
I think the RFC should be much clearer about what property access actually means within
each accessor method, as I expect users to be very surprised by this behavior.
This is also looks like it could lead to surprises:
Within get, $this-Hours is the raw shadowed property.
Within get, parent::$Hours is accessed via
parent::__getHours()/parent::__setHours().
Also, is there no way to access the shadow property within isset/unset? If not, is there a
good reason to not allow it?
Also, do/should multiple property accessors interact? Consider:
class Foo {
public $a {
get { $this-a = 1; return 2; }
}
public $b {
get { return $this-a; }
}
}
$foo = new Foo;
$foo-a; // 2 (but shadowed property is 1)
$foo-b; // 1 or 2?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On Jan 2, 2013, at 10:24 PM, Clint Priest cpri...@zerocue.com wrote: I've updated the Shadowing section of the RFC which I hope clears this up, it also includes a slightly modified version of your example at the bottom with comments. Updated RFC really helps. The notion of $this-prop access semantics depending on which accessor you're in seems important for the RFC as I think it will seem foreign to a lot of devs. When I make traditional PHP accessor methods, I have complete control; if I want getFoo() to set private $foo without calling setFoo(), I can. Not so with real accessors. Probably a good thing :) One more concern, sorry if it was covered already: will case-insensitivity of methods mean you can't define getters for both $foo and $Foo? Steve -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call closure stored as object property directly without use of temporary variable
Adam,
On 12/8/12 4:48 PM, Adam Jon Richardson wrote:
call closures that are stored as object properties directly without having
to make use of a temporary variable.
...
$o = new stdClass();
$o-func = function(){
return 'Yes!';
};
$o-func();
The following expression avoids PHP's dilemma of distinguishing prop/method, but fails
because you can't execute an expression:
($o-func)();
Similarly if $a is a Closure, $a() works but ($a)() fails.
If these could be made to work, would it break BC? And *should* they be made to
work?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/15/12 3:11 PM, Anthony Ferrara wrote: That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED to it in 5.5. Update the documentation, and start a PR campaign to get off This may be a narrow PR channel, but I'd focus on getting @deprecated into the built-in function stubs in all the IDEs. In PhpStorm I see lines through the function name, and there's a deprecation section in the Inspect Code report. I'm much more likely to notice those than notice changes in online docs or error log notices. But more importantly, anyone writing *new* code will see that feedback immediately. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
On 10/26/12 6:37 AM, Clint Priest wrote:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Some people are in favor of the internal functions being generated by an
accessor
declaration should be invisible and non-callable directly. Others are in favor
of leaving
them visible and callable.
If we leave them callable,
* What would be the effects of users defining the internal methods (in both cases of
if/if not the accessor is also defined)? Considering current magic methods are
*purposefully designed* to be implemented by the user, I expect users to try this and, if
it works, release code with it.
* I assume one could use them as regular methods?
* call_user_func([$foo, '__getpropName']);
* $foo-{__get$propName}
I apologize if these were already covered.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 20 Oct 2012 09:49:39 -0000 Issue 2820
On 10/20/12 10:45 AM, Rasmus Schultz wrote: Just drop the idea of read-only altogether, please - it's so marginally useful in the first place, unconventional compared to other languages, and Read-only is perfect for value objects, where the alternative is a bunch of protected props and getters: $color = new Color(255, 0, 0); $color-r; Steve -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: alternative callback syntax
On 9/19/12 2:37 AM, Sebastian Krebs wrote: 2012/9/19 Steve Clay st...@mrclay.org mailto:st...@mrclay.org https://wiki.php.net/rfc/__alternative_callback_syntax reason I like 'Classname::class' for classes) I don't like, that functions will look like classes with a static property function then ... FWIW, here are the syntaxes I've considered: func_name; // parser can't distinguish from constant callablefor func_name; // adds reserved word, token func_name::callable; // adds reserved word func_name::function; // in RFC Steve -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: alternative callback syntax
On 9/19/12 9:26 AM, Ivan Enderlin @ Hoa wrote: callable is already a reserved word (T_CALLABLE). Oh, good. It's not listed here http://php.net/manual/en/tokens.php Steve -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: alternative callback syntax
On 9/19/12 1:19 PM, Andrew Faulds wrote: I completely agree. How about function_name? Resembles C (function pointers!), and unless I'm getting confused, it isn't currently legal syntax for something else. $cb = Foo::doSomething; $cb = foo_doSomething; $cb = $obj-doSomething; The last looks like a reference to a property, though having verb method names would help distinguish. Not sure if the ambiguity would make this difficult to implement. Some other ideas: $cb = (callable) $obj-bar; $cb = callable $obj-bar; $cb = callable::$obj-bar; $cb = $obj-bar::callable; Steve -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: alternative callback syntax
On 9/19/12 2:01 PM, Andrew Faulds wrote:
Some other ideas:
$cb = (callable) $obj-bar;
Ah, but (callable) that won't work for global functions, since (callable) is a
cast, and
(callable) is not usable as a cast (at least in 5.4.7):
$a = (callable)'str'; // Parse error: syntax error, unexpected 'callable'
(T_CALLABLE)
This could work, and it makes sense to me at least.
$cb = {mysql_real_escape_string};
$cb = {mysql_real_escape_string};
I'll add these possibilities to the RFC soon.
Steve
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
On 9/18/12 7:30 AM, Pádraic Brady wrote: That's all. The RFC should be self-explanatory and feel free to pepper ... https://wiki.php.net/rfc/escaper I like where this is going and agree that PHP officially embracing an API would be helpful even for users stuck on old PHP versions. First issue: I've not studied the referenced PHP implementations, but in cases where multiple contexts seem to apply it's not clear from the RFC which function(s) should be used, and if multiple, how their calls would be composed. Examples: HTML style attribute: escapeHtmlAttr, escapeCss, or both? HTML on* attributes: escapeHtmlAttr, escapeJs, or both? HTML href/src attributes: escapeHtmlAttrs, escapeUrl, or both? HTML script/style elements: Is escapeHtml needed? I can probably correctly guess some of these, but I think ideally the method and class names should make this more obvious. If escapeJs is only for string literals in JS code (again, the name doesn't make that clear to me), what does escapeCss actually do, since string literals aren't very common in CSS? Example code would be helpful to clarify both issues, but I still think naming is very important here, and with all the contexts we have to consider the names in the RFC don't scream what to use them for. Steve -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
On 9/18/12 1:55 PM, Stas Malyshev wrote: Again, nowhere it is said that you can not apply different filters to different data or different context. Again, you narrow down definition of filtering, to which I see no purpose unless you seek to arrive at pre-determined conclusion that we need to duplicate APIs because it's called filter. I agree that filtering can mean general processing of data, but if we embrace this definition in the filter extension, why not deprecate *all* string functions and replace them with FILTER_SANITIZE_* constants? I'd argue because naming matters, and *option* constants should not be used to wildly change behavior. Filter has already gone down this road--I doubt the value added by having a second, much more verbose way to call htmlspecialchars()--but I don't see why we must continue down that path. Steve -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: alternative callback syntax
Hello, https://wiki.php.net/rfc/alternative_callback_syntax is a proposal for a simple alternative syntax for creating function callbacks. The basics: Given a function/method call, replace the argument list with ::function. PHP would evaluate this as a callback for the function/method, fully resolving any class/function names according to the current namespace and any use statements. In my opinion this syntax would aid readability and benefit users via fewer typos and namespace errors, and via (hopefully) better IDE support. I welcome any feedback. I don't have adequate C skills to offer a patch at the moment, but I generally read everything I can get my hands on about how PHP features are implemented and am not afraid to jump in. Thanks for your time. P.S. I've kicked around this idea around for awhile, but Ralph Schindler's idea for using ::keyword provided a better path to BC, and more attractive/meaningful syntax. P.P.S. I'm unaware if it's customary to throttle the release of RFCs, so I apologize for hogging any attention away from those under discussion. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About CVE-2012-0831 (magic_quotes_gpc remote disable vulnerability?)
Hi Kousuke,
On Thu, Feb 16, 2012 at 06:14:51PM +0900, Kousuke Ebihara wrote:
(12/02/16 16:24), J David wrote:
reported magic_quotes_gpc as Off/On, but magic quotes behavior started
happening anyway. Of course I just moved the configuration to the
I've also confirmed this behavior in snapshot version of PHP 5.3 (Build on
Feb 16, 2012 00:30 UTC).
I tested my https://gist.github.com/1840714 script.
And I've got the following result::
$ wget -q http://localhost:8080/phpinfo.php; -O - | grep Loaded
Configuration File
trtd class=eLoaded Configuration File /tdtd
class=v/private/tmp/php.ini /td/tr
$ cat /private/tmp/php.ini
magic_quotes_gpc=On
$ wget -q http://localhost:8080/cve-2012-0831.php?a=' -O -
PHP Version: 5.3.11-dev
magic_quotes_gpc: 0
$_GET['a']: \'
I think magic_quotes_gpc is not disabled. All of the PHP C sources might use
PG(magic_quotes_gpc) to access to that setting value, so that result might
not be affected zend_alter_ini_entry_ex().
But a result of ini_get() uses a setting value after the
zend_alter_ini_entry_ex() calling, so it reports 0.
The above is just my guessing because I'm not an expert of PHP C source code
but probably it is not bad guessing, I think.
You're seeing the behavior reported by Ondřej Surý in
https://bugs.php.net/bug.php?id=61043, where magic_quotes_gpc is
configured on, but ini_get('magic_quotes_gpc') returns that it's
disabled, even though magic quoting is still happening.
That's different from the behavior that J David reported, where he
configured it *off*, but saw magic quoting still happening.
It would be great to get comments on the patch provided by Ondřej
in the bug report to know if it's the correct fix, and if so, get it
committed to the 5.3 branch.
Thanks.
--
Steve Beattie
sbeat...@ubuntu.com
http://NxNW.org/~steve/
signature.asc
Description: Digital signature
[PHP-DEV] Debugging internal array corruption
Hi all, Looking for a pointer on internals layout. I've an issue whereby php is seg faulting during a print_r, I can see that the corruption has already occurred in the hash at the start of the print_r, so now I want to set a breakpoint at the point that an entry is added to an array (so I can then add a watch on the correct address). Any pointers as to the file/function that I'd be looking for? The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email 'techni...@brendata.co.uk' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk
Re: [PHP-DEV] Re: What is still missing from windows builds ...
Perhaps since http://pecl4win.php.net/ has been down for several years, it is time to just remove all the references to it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
With Traits, interned strings/hash table optimizations, array deref., Can we bring the strings/hash table optimizations to PHP 5.3.x please? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About optimization
On Sat, Jan 30, 2010 at 9:37 PM, Richard Lynch c...@l-i-e.com wrote: On Sat, January 23, 2010 2:26 pm, steve wrote: The guys at Zend muscled in to change the culture as well, and have I'm not sure that's a fair representation of the historical reality of how Zend came into existence... OK. I don't think it is/was a bad thing. PHP needed that. And how is the non-Zend PHP not full? Well, one would think that an op-code cache would have made it into the PHP distribution by now, but such a thing would have competed with the Zend products, so they weren't. Enough time has passed for a new round to wrestle control. We'll see how the FBJIT goes. Which just goes to show, if you really want something done, put some muscle into, take over or fork. Or keep to yourself. Sounds good. Which are you doing? :-) I was talking about the FaceBook JIT -- FBJIT. I understand they didn't get quite as much performance out of it as their cross compiling. For now at least. Two different groups of people anyhow. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About optimization -- What every programmer should know about memory
Just as a reference point should someone come across this thread at a later date, and are interested in how memory usage changes performance, this was one of the articles I found that does a decent job, somewhat dated: What every programmer should know about memory http://lwn.net/Articles/250967/ You can look at the part about what programmers can do: http://lwn.net/Articles/255364/ And don't forget about the tools like valgrind and perfctr. Also oprofile, pagein, pfmon, callgrind. iam On Mon, Jan 25, 2010 at 4:59 PM, steve iamste...@gmail.com wrote: This isn't about server costs. It is about choosing the right tool for the right part of the job. A Javascript library for the client-side frontend, PHP for the server-side frontend, C/C++ for your middle-layer and an appropriate datastore behind it all and you can build amazing things with PHP. The largest destinations on the Web today are written exactly like this. This is a tremendous insight. No where near my experience. (Neither is cheap hosting for individuals). Faster PHP means smaller webfarm, and if you pay for that webfarm, then these things matter. At any rate, thanks for the long description. And I do notice the nice tone in contrast to mine that day. Sigh... All I can say on this is, send some patches to the list. PHP improves through code. True, true. But I remember a history of push back to such things, and even if now that is no longer the case, the price of political engagement is too high (that is, just explaining the stuff, etc). We're at the point of migrating away (in small tiny steps) anyhow, but I hope others that have experience and extra manpower speak up. There are some interesting internal forks of php out there that are cleaner and faster than what we could contribute anyhow. It seems that you did not look closely to the improvements made to PHP 5.3. Sadly, I'm not sure 5.3 is in the cards for this year, and the stock build wouldn't do. Needs work on method dispatch. iamstever -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About optimization
This isn't about server costs. It is about choosing the right tool for the right part of the job. A Javascript library for the client-side frontend, PHP for the server-side frontend, C/C++ for your middle-layer and an appropriate datastore behind it all and you can build amazing things with PHP. The largest destinations on the Web today are written exactly like this. This is a tremendous insight. No where near my experience. (Neither is cheap hosting for individuals). Faster PHP means smaller webfarm, and if you pay for that webfarm, then these things matter. At any rate, thanks for the long description. And I do notice the nice tone in contrast to mine that day. Sigh... All I can say on this is, send some patches to the list. PHP improves through code. True, true. But I remember a history of push back to such things, and even if now that is no longer the case, the price of political engagement is too high (that is, just explaining the stuff, etc). We're at the point of migrating away (in small tiny steps) anyhow, but I hope others that have experience and extra manpower speak up. There are some interesting internal forks of php out there that are cleaner and faster than what we could contribute anyhow. It seems that you did not look closely to the improvements made to PHP 5.3. Sadly, I'm not sure 5.3 is in the cards for this year, and the stock build wouldn't do. Needs work on method dispatch. iamstever -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About optimization
I doubt anyone does I1/D1/L2 cache profiling for PHP. I did a little bit of CPU cache profiling of PHP using oprofile, more out of curiosity than anything. It was a couple of years ago now. http://wikitech.wikimedia.org/view/Oprofile But you don't need oprofile, you can make changes based on theory, and then measure the execution time of the result. I don't know where to go with that. I so much agree. Yet it so much depends on what the theory is based on. But measurement and a decent test matrix is key. valgrind/callgrind and the others can help. Honestly, I think people should stay out of coding languages (either interpreters or compilers, where interpreters are the more complex case often best made easier by doing JIT) unless they have done CPU design. It is not like the pre-386 days. These days CPUs are designed for the compilers (either where they are, or likely where they will be). The CPU designer decides how the compiler should operate. It is their theories that matter. Not always -- just like in literature -- the author may create something that is beyond their own grasp and best understood by others. PHP doesn't ship with an optimizer, byte code cache, or JIT. But community members are developing those things nonetheless. eAccelerator has an optimizer, there are several so-called byte code caches, and Roadsend is a promising compiler project. Have been developing for a more than a decade... PHP4 was the last time there was real performance improvements in PHP itself. The fact that there are several so-called byte code caches does not equal a good thing. It means that PHP is broken and lots of people are trying to fix it. It also means that none have succeeded, as that would mean that one of them would be included in the PHP core by now. Rasmus had the idea that it should do simple things and be easy, and if you were going to do anything else, then you should have the money to do so. Fair enough really. Rasmus is not the whole community. Like a founder of a company that sets the corporate culture, don't count Rasmus out so easily. Founders earn such power. Until they are booted. It is not going to, nor should it, happen here. The guys at Zend muscled in to change the culture as well, and have succeeded to a large degree, pushing PHP into the enterprise by offering a full version of PHP, not free of course. And thus the reason for not having a byte code cache in the core. And the whole optimizer which was their decoder part of their encoder project was just making bad karma. Enough time has passed for a new round to wrestle control. We'll see how the FBJIT goes. Which just goes to show, if you really want something done, put some muscle into, take over or fork. Or keep to yourself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About optimization
Having 8 cores with only 1G of ram would be a weird server config. A single socket quad-core with hyper-threading and 2GB RAM for a 32-bit webserver is not weird. Not everyone is Yahoo where you can just throw money around. For Mr. everyone has 8GB of memory and tiny little data sets Lerdorf, I could point out that reducing the average zend_op size and placing strings close to other op data will also make execution faster, due to the improved CPU cache hit rate. I don't think PHP has as much support as you think it does. There is no big supporter to fund a real development drive like that. I doubt anyone does I1/D1/L2 cache profiling for PHP. PHP doesn't ship with an optimizer, byte code cache, or JIT. Rasmus had the idea that it should do simple things and be easy, and if you were going to do anything else, then you should have the money to do so. Fair enough really. Kinda reminds me of Firefox and its speed and memory usage. Machines have lots of RAM, so lets use it, blah, blah, blah. When they finally decided to do mobile phones, they realized what a mess their startup times were, what a hog it was with memory, etc. They even do *some* cache profiling now! I'll never use Fennec, but happily use the results in Firefox. You should see the careful work that went into Google's V8. But most of the time, the act of optimising will take longer than just compiling and running the code, because you have to make decisions about whether something can be optimised and the best way to do it. Yeah, like no one should cache or JIT a web page. No loops. The use pattern is to just look at a web page once and then the next. I think Microsoft still says that. (Admittedly, Microsoft ships its own opcode cache for PHP.) iamstever -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: wiki/windows.php.net system update
Yeah, pecl for windows was last working in 2008 -- a couple of years ago. Time flies... Pierre, could you build a php_memcache-5.2-nts-Win32-vc9. It would be much appreciated! Thanks, iamstever On Sun, Jan 10, 2010 at 8:24 AM, Pierre Joye pierre@gmail.com wrote: On Sun, Jan 10, 2010 at 4:37 PM, pan p...@syix.com wrote: Pierre Joye wrote: hi, The wiki.php.net and windows.php.net box is being updated. The sites will be back online asap. Has it been a full year since PECL for Windows was to be ready? Just asking. Btw, many popular exts are frequently updated and available here: http://downloads.php.net/pierre/ Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- 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] Re: [PHP] Re: PHP 5.3.0 Released!
On Thu, Jul 2, 2009 at 3:54 AM, Michael A. Petersmpet...@mac.com wrote: Nick Cooper wrote: Does anyone have any further information on the PECL Binaries for 5.3, will they be released? I don't, but I suspect it is just a matter of compile + test. We develop on Windows and deploy on Linux, so without the PECL Windows binaries, we won't even try and move to 5.3. Surely, we are not alone... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.9RC1 Testing
On Thu, Feb 5, 2009 at 4:10 PM, Pierre Joye pierre@gmail.com wrote: Windows binaries are now available in the usual place: http://windows.php.net/qa/ Wouldn't by chance be able to add APC to that? It has been 13 months since APC was built for Windows. (Never for a NTS version, as far as I know, but would be nice to have...). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.7RC1 Testing
The more that gets moved from php into pecl, the more many of us rely on pecl builds to test php. Specificly in regards to 5.3 and 6.0... On Fri, Oct 17, 2008 at 8:52 AM, Pierre Joye [EMAIL PROTECTED] wrote: hi, All references are now updated, in http://qa.php.net http://bugs.php.net and http://snaps.php.net Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- 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] str_getcsv
The main branch? PHP_5_X are the stable branches, HEAD is the development branch (at least in theory ...) So stuff is added to HEAD and merged bacxk when it's stable enough and need (and somebody cares) +1 from me, though... johannes Now, if we could work the phrase namespaces into this somehow we'd probably have this in HEAD within a few days. On a serious note, there seem to have been quite a few commits to MAIN over time, so I wonder what else is lurking there that could be useful? If nobody else is doing this then I'm happy to build a diff, What's involved in getting a commit account for CVS or is it easier to just email a diff set to somebody (in which case, who?) Steve The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email '[EMAIL PROTECTED]' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] str_getcsv
Can anybody suggest a reason why this has never moved from main to php_5_2 or php_5_3? It was added to MAIN in dec '06 Steve The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email '[EMAIL PROTECTED]' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] str_getcsv
If it's not stupid question, what is the main branch for? Presumably the other branches aren't just branched from this at a point in time or we'd have this in there. High? Nah, just chilled after a glass or two of wine. Can't beat a good corporate disclaimer! Steve From: Hannes Magnusson [mailto:[EMAIL PROTECTED] Sent: Mon 20/10/2008 9:46 To: Steve Hanselman Cc: internals@lists.php.net Subject: Re: [PHP-DEV] str_getcsv On Mon, Oct 20, 2008 at 22:43, Steve Hanselman [EMAIL PROTECTED] wrote: Can anybody suggest a reason why this has never moved from main to php_5_2 or php_5_3? I did wonder the same months ago, but noone seemed to care, and I had no use for it myself so I never bothered merging it :) The information contained in this email is intended for the personal and confidential use Are you high? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email '[EMAIL PROTECTED]' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Using the non-VC9 nts build (and after erasing sqlite files so they get created from scratch) I can have PDO sqlite create a table, and add records, but not delete records (SQLSTATE[HY000]: General error: 1 SQL logic error or missing database). Reverting to 5.2.x works again. We use a cache layer that can switch between APC, memcached, and sqlite depending on what we are trying to cache. Locally though, APC is not available for these PHP builds, and i don't have memcached running, so I have to use sqlite. Which is not working. So I'm zero for three and can't test much else. When is alpha 3? On Wed, Sep 10, 2008 at 7:33 AM, Daniel Henning [EMAIL PROTECTED] wrote: Hi lists, there is a Problem with pdo_sqlite in PHP 5.3. (downloaded half an hour ago from snaps) I've sent a report here : http://pecl.php.net/bugs/bug.php?id=14098 Anyway php_pdo_sqlite_external doesn't have this problem but isn't available in 5.3 windows-builds anymore. Is it possible to activate this extension by default since it is the same source like normal pdo_sqlite? kind regards, Daniel -- 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] PHP Suspendable requests for Apache
Not true.. Tomcat supports comet, and it runs on APR. Yes, the thread pool is small, but there is always a solution. The idea is to return the thread back to Apache's thread pool while waiting for an event: http://tomcat.apache.org/tomcat-6.0-doc/aio.html Then convince the Apache developers to implement the feature in Apache httpd... They are not interested. If you want to have comet apps and stream bits of data fast for email (gmail) or stockprices in the middle of your text (marketwatch) then you have to go use other tools. If you *must* use PHP, you will have to write your own long lasting web server in PHP -- but note that PHP was not designed for that. Neither was apache. There is a reason why all the comet stuff is written in other languages and use other web servers. Best bet -- use another tool stack. Typically you have have it call into other code as needed (like PHP) for things like authentication or data collection, and since the usage pattern is different, you probably want it on a separate cluster anyway. http://cometdaily.com/ is a better channel to gather some info. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP] PHP 5.3.0alpha2
OK, I finally went to do it and this link doesn't work: PHP 5.3.0alpha2 VC9 x86 http://downloads.php.net/pierre/php-5.3.0alpha2-nts-Win32-VC9.zip On Thu, Sep 4, 2008 at 5:23 AM, Johannes Schlüter [EMAIL PROTECTED] wrote: On Wed, 2008-09-03 at 23:36 -0700, steve wrote: It is pretty much include() and its relatives. Autoloading with a lot of possible include paths. I'm sure if you had a Zend Framework App and put it on Windows, and took out all the require_onces with paths in them Try 5.3 please, our implementation of realpath(), one of the biggest require_once slowdowns, as well as other parts were improved quite a lot. Feedback is welcome :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP] PHP 5.3.0alpha2
Good to know. And it makes it easier to use the Apache builds from http://apachelounge.com. On Wed, Sep 3, 2008 at 9:06 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Btw, contrary to what many believe, 32bit PHP tends to perform better than 64bit PHP. So unless there's a really good reason why you want 64bit I wouldn't waste too much time on that. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP] PHP 5.3.0alpha2
That's great! I like all the different builds. Two things that pop out: 1) What are some recommended non-official builds of Apache2 in x64? and 2) Will there be PECL builds also? On Tue, Sep 2, 2008 at 3:27 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hello! Johannes has packed PHP 5.3.0alpha2 yesterday, which you can find here: http://downloads.php.net/johannes/ Windows binaries (optimized for various versions of Windows) are available from the new website dedicated to PHP's windows binaries: http://windows.php.net/downloads.php Please test it carefully, and report any bugs in the bug system, but only if you have a short reproducable test case. If everything goes well, we can release it somewhere at the end of next week. regards, Lukas and Johannes -- PHP General Mailing List (http://www.php.net/) 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] Re: [PHP] PHP 5.3.0alpha2
None yet, I still have to create some. Apache may provide some when they have began the move to VC9. VC9 Apache builds can be fetched from http://apachelounge.com, they are known to work very well. Hmm.. that is a good link. I had forgotten about them. Ideally, I'd like to get a all 64bit setup with Apache - FastCGI - PHP (nts). PHP is so much slower on windows, though a lot of it has to do with file handling, a Windows specific slowdown I guess. Merging all the PHP files into one speeds things up by 400%. But since I develop on a local windows build, and deploy on Linux, the merging of files is of little help. It is sort of a hail-mary that VC9 might somehow improve things, and might as well go 64bit at the same time. and 2) Will there be PECL builds also? Yes, but directly in pecl.php.net package homepage. Does that mean there will be a package of them as before? But for all the build targets like your new site has? http://windows.php.net/downloads.php is a huge improvement. Thank you very much! -s -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] TracingPHP
With all the news of TraceMonkey bringing an order of magnitude speed increase to JavaScript, it was only a matter of time before someone brought up (again) the idea of doing JIT for PHP, so I'll take the flack and let it be me. The part that knocked me over was the work began just about 60 days ago part. Of course, that needs to be put in context -- they were working on tracing in Tamarin before trying it in SpiderMonkey, so there was a huge amount of time dedicated building up experience that is not counted in that 60 days. Even so, I think there is good evidence that such a project can be done in a reasonable timeframe. The largest users of PHP with large PHP server farms could see significant savings in hardware, and really ought to consider such a project. (And please, no comments on how speed of PHP doesn't matter because databases are slow -- such is not the case for people with such large PHP server farms). So, perhaps this is the right time, with a nice case study, for PHP coders at some of these big users to pursue resources for JIT in PHP. Cough. Facebook. Cough. Yahoo. Cough. Please excuse my coughs... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] TracingPHP
I know llvm allows nicer licensing such that the runtime can be embeded -- is this what this extension does? On Mon, Aug 25, 2008 at 10:51 AM, Sebastian Bergmann [EMAIL PROTECTED] wrote: steve schrieb: With all the news of TraceMonkey bringing an order of magnitude speed increase to JavaScript, it was only a matter of time before someone brought up (again) the idea of doing JIT for PHP, so I'll take the flack and let it be me. http://cvs.php.net/viewvc.cgi/pecl/llvm -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- 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] TracingPHP
Has anyone had success compiling PHP with LLVM? On Mon, Aug 25, 2008 at 10:51 AM, Sebastian Bergmann [EMAIL PROTECTED] wrote: steve schrieb: With all the news of TraceMonkey bringing an order of magnitude speed increase to JavaScript, it was only a matter of time before someone brought up (again) the idea of doing JIT for PHP, so I'll take the flack and let it be me. http://cvs.php.net/viewvc.cgi/pecl/llvm -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- 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] 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] PHP 5.2.6RC2 Released
Windows binaries should become available in short order as well. What happened to that? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: stevseea
I have PHPT tests to contribute. I am working with others who contribute tests including Raghu Kumar and Zoe Slattery. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] How to integrate PHP with my homegrown server
Hi, as an experiment I have a simple Java based server that listens on port 80 and can serve files just fine. I'd like to extend it to support PHP but am looking for guidance on how to do that. Can someone point me to instructions? My first attempt was to just call the php.exe command line interface to launch the php interpreter, capture the html and send it back to the caller. That works well, but I can't seem to figure out how to deal with parameters. For example, if the url would be this on the server: http://some.server.com/mypage.php?parm1=Helloparm2=Goodbye and in mypage.php I do something like this: $echo $_GET[parm1]; then how do I test this via the PHP command line? If the command line doesn't have a way to cause $_GET to be populated, then what other way of invoking PHP could I use? -- Steve -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to integrate PHP with my homegrown server
Daniel Brown wrote:
On 8/24/07, Steve Francisco [EMAIL PROTECTED] wrote:
[snip!]
If the command line doesn't have a way to cause $_GET to be populated,
then what other way of invoking PHP could I use?
-- Steve
Steve,
You'd need to transpose the $_GET variables from the request to
$argv variables via the CLI. I don't know exactly how Java would
handle it, but the PHP equivalent (though rather recursive and
unnecessary, it's just here for demonstration purposes) would be:
Thanks Daniel, I can certainly do that in Java without much trouble,
however I was hoping to avoid needing to do things in each php file to
convert argv into $_GET. I want to be able to serve standard PHP
without modifying each one.
But you made me realize there is a way. I wrote a small pre.php file
like this:
?php
#
for($i=1;$icount($argv);$i++) {
$variables = split(=,$argv[$i]);
$_GET[$variables[0]] = $variables[1];
}
?
and in my php.ini, I set this:
auto_prepend_file =e:\php523\pre.php
Now it works fine without having to modify the php code! All I need to
do is have the Java code set up the html parms as argv, and I'm done.
-- Steve
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] phar apc
Before reading the thread on the idea of a PHP 5.3 branch, I had never heard of phar, so please excuse my neophyte questions, but I couldn't find a reference with the information. On a single website application environment (as opposed to a shared host type of thing), what are the performance characteristics of using a phar file to replace a largish collection of php files? Does the performance improve or not? does a fast-cgi based installation make a difference? Are stat calls for included files short-circuited since it is all really one file? Does this improve things in windows where file calls seem so damn slow? Linux? Most important, how does it work with APC? thank you for any answers or references to points of study on the web. -s -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 4.4.6RC1
Is there a list of fixes so far in this release? I've found a crashing bug that came in 4.4.5 that was not in 4.4.4, and related, I believe, to some string processing. I'm narrowing it down right now. On 2/20/07, Derick Rethans [EMAIL PROTECTED] wrote: Hello! there is a critical issues in PHP 4.4.5: - when register_globals = On, sessions don't work correctly (segfaults). Because of this I'd like to release a 4.4.6 soon with this fixes. As there is also an upgrade to pcre 7.0 we'd need atleast one RC, which I plan to release on Thursday. Any opinions? regards, Derick -- 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] mod_fast_apache, FastCGI, and mysqli
Having cross-process persistent connection pool for PDO would be great. Having a better system on the DB side would be great too (as it looks to be for Oracle). The MySQL server test looks promising. I like the Apache 2.2 model of using epoll to have one thread handle all the keep-alive connections which in mysql I guess would be sleeping connections. Don't like the one thread per connection system currently, though it has not presented any deal-breaking problems. Well, not yet anyway. :) On 2/6/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Christopher Jones wrote: steve wrote: Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
On 2/6/07, Rasmus Lerdorf [EMAIL PROTECTED] wrote: A couple of points. mysqli doesn't have persistent connections because the authors of that particular extension don't think it is a good idea. It's not a PHP-wide thing, PDO and others do have it. Yes, point taken. I just figured they were trying to fix an issue that people happened upon since most just use Apache 1.3 with mod_apache. If you are going to FastCGI for performance and scalability reasons because you don't want a heavyweight web server process handle a dynamic request, then you are essentially just using the web server as a proxy which isn't really what it was written to be. There are much more effective reverse proxies out there that can do that. Let's not get carried away and make it out to be the solution to everything, because it certainly isn't. The larger companies have Akamai or Akamai-like solutions for all their static file needs, and most of the smaller ones have thttpd or lighhttpd lightweight servers handling those or they have stuck Squid or Pound out in front. For these sorts of architectures the extra handoff to a FastCGI process doesn't make much sense because every request that gets through to the web server is going to be a dynamic one so Apache1 or Apache2-prefork is managing these process-based PHP interpreters in exactly the same fashion that FastCGI would with the exception that you have more control with the richness of Apache and you are closer to the actual request and can make use of the rich set of Apache modules out there. Hmmm. Using a reverse proxy like Pound will still connect to PHP via a webserver since PHP will be wrapped up in Apache. Maybe running apache this way doesn't add much overhead. I have not done this setup, so I am ignorant to the particulars. But I'm not sure if Pound would hold open the keep-alives (with 2000 open threads?) or if that would go all the way through to the apache (where there would now be 2000 processes). Having Keep-Alive off does simplify things greatly, but I am assuming it is there. :) Just an FYI: I have two setups that I have to deal with: LVS servers - Apache servers - LVS - PHP servers - DB servers Here the LVS servers act as firewall and load balancer (level-4 switching in kernel mode), and the Apache servers talk to the PHP servers via FastCGI. We are going to change the Apache servers to lighttpd servers to avoid the need for the middle lvs since lighttpd can load balance fastcgi and that middle lvs has no backup. cough And lighttpd deals with keep-alives ok as far as I know. My setup is: LVS servers - Apache / PHP servers - DB servers This setup has PHP running on the same servers as Apache communicating via FastCGI. Having Keep-Alive turned on, I can't think of how to handle many simultaneous connections. Servering static content isn't really the issue, though it contributes. Its having all those sleeping connections. I only know that LVS does a great job with them and Apache 2.2 event MPM does a good job. So that is where I'm coming from. Hopefully I sound less nutty. So yes, for the ISP case, I am all for suggesting that FastCGI should be the default way to run PHP. We've been saying that for a while actually. But in other cases you are going to have a much harder time convincing me. A. Small web server case: not much different performance wise to use FastCGI B. Using Keep-Alive on a small server starts causing problems for noobs that use persistent connections, using FastCGI doesn't. C. Load balanced multiple server medium sized site like above gets lots of benefits, including speed, less resource usage (fewer servers!) use of both persistent db connections and persistent http connections. D. ISP's use FastCGI for security issues. (so should we all). E. Large sites use Akamai, don't have their people worrying that adding servers comes out of their paychecks, can basically do any number of configurations, efficient or not, and have labs to test such arrangements. OK, I sound jealous here Not to mention, the module specific stuff would be identical for all groups above. And the fastCGI module for apache has already fallen into disrepair. I like the idea of PHP taking it rather than apache, as it could be made into a PHP only fastcgi module and have easier options for users. And maybe get fastcgi load balancing like lighttpd. And I actually know a little bit about running PHP in extremely high-traffic situations. And thank you for your insights!!! Particularly if you have advice on scaling COMET type connections with data from PHP. That is a whole other story... steve -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Thanks! That is a blast from the past! I never got it working properly, and since using PHP in FastCGI mode has eliminated the problem by 80%+, hopefully I won't have to revisit it. But thanks again! I never know! -s On 2/7/07, Reinis Rozitis [EMAIL PROTECTED] wrote: Christopher Jones wrote: I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html Besides there are some third-party solutions like SQLRelay http://sqlrelay.sourceforge.net/ rr -- 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] mod_fast_apache, FastCGI, and mysqli
that directs traffic to an apache 1.3 server just for dynamic pages (very similar to the previous split but using http protocol instead of the fastcgi protocol, or using both approaches)??? OK, thanks for listening to my suggestion. Here is the short version: a) copy the fastcgi apache module to php's source b) make the config options easy for the basic user c) included in future distributions d) make default at a later point e) bring back persistent connections f) remove thread safe code??? maybe crazy idea -steve-- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.1RC3 Released
On 1/20/07, Antony Dovgal [EMAIL PROTECTED] wrote: Has something changed with realpath() (at least on windows, my only test)??? In 5.2.0 if the file does not exist, it returns false, but in 5.2.1RC2 and 5.2.1RC3 it returns the path to a non-existing file. (Used fastcgi/nts version to test) Please fill a report @ bugs.php.net. Thanks in advance. Since I have the thread safe version of rc3 running now, and it is not there, i suspect that it might be a build issue. Do the two use or link to different core libraries? 3. When using RC3 as a handler (thread safe version), phpinfo reports PHP 5.2.0 but under apache2handler is says 5.2.1RC3??? Most likely you forgot to delete old php5ts.dll. Yes, found that, thanks... I knew I had to have done something wrong... -steve-- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.1RC3 Released
Hi, a couple of things (and maybe I need some help, and everything is assuming windows): 1. Has something changed with realpath() (at least on windows, my only test)??? In 5.2.0 if the file does not exist, it returns false, but in 5.2.1RC2 and 5.2.1RC3 it returns the path to a non-existing file. (Used fastcgi/nts version to test) 2. I love having the nts versions. That way I can use FastCGI on my dev machine and have it setup like the servers. And a bit faster. However, RC3 run times are sooo much longer than RC2 that the FastCGI server often ends up canceling and gives the browser a Internal Service Error 500... 3. When using RC3 as a handler (thread safe version), phpinfo reports PHP 5.2.0 but under apache2handler is says 5.2.1RC3??? And it no longer has the real_path bug above. I no longer have any 5.2.0 files around, and even tried restarting the machine to no effect. I always install manually, never using the msi installer. Hope this report helps in any way. Thanks! -s On 1/19/07, Edin Kadribasic [EMAIL PROTECTED] wrote: Windows build is ready for download too: http://downloads.php.net/edink/php-5.2.1RC3-Win32.zip (6dd32e4a2ec2dd67efe42edcba3fdee5) http://downloads.php.net/edink/php-5.2.1RC3-win32-installer.msi (50c20632cc232da6ae13c302339df0b5) http://downloads.php.net/edink/pecl-5.2.1RC3-Win32.zip (fa31e1c0ad54514b19357b52aadbb9e5 ) http://downloads.php.net/edink/php-debug-pack-5.2.1RC3-Win32.zip (cd86bc20eb524fd7e72ec2d43e0de13b) And the FastCGI non-thread safe build (WARNING: the build below can only be used with CLI/CGI/FastCGI) http://downloads.php.net/edink/php-5.2.1RC3-nts-Win32.zip (61b6d9146b871b72f26cc2a44d294941) http://downloads.php.net/edink/pecl-5.2.1RC3-nts-Win32.zip (e4331988dc8e692dc5bb5f079f54d776) http://downloads.php.net/edink/php-debug-pack-5.2.1RC3-nts-Win32.zip (5c83f3ec7d7fdaa202aac565d38864fe) Edin Ilia Alshanetsky wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The 2nd release candidate for PHP 5.2.1 is now available for download. The tarballs can be found here: http://downloads.php.net/ilia/php-5.2.1RC3.tar.bz2 (d3889eda8c3471ce7cf2adb35a4de736) http://downloads.php.net/ilia/php-5.2.1RC3.tar.gz (c5b3e5540d1951d4c4b976b8a39c09ab) and the Win32 binaries will be available in short order. Since the last release, there are over 20 different bug fixes resolving some annoying engine issues such as the tempval leak inside foreach(). We do not anticipate any regressions to be introduced by this RC, but I would still like to ask everyone to take a few minutes and test it against their code base. If you come across any issues please report them at http://bugs.php.net/. Depending on the stability of this release it may either be followed by a final release or another RC, therefor your feedback is critical to determining whether or not the code is stable enough to warrant the 5.2.1 final. Ilia Alshanetsky 5.2 Release Master -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFsBJOLKekh381/CERAq/MAKCKg7buIpB9hXWrtnfHN7hQPB6akgCeJy8q Q/HBl5G15afjTjebEaILHlE= =tsFU -END PGP SIGNATURE- --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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.4.5
Will there be an upcoming release (I don't mean ever, but soon) that incorporates this fix: http://cvs.php.net/viewvc.cgi/php-src/ext/standard/html.c?r1=1.63.2.23.2.2r2=1.63.2.23.2.3view=patch I do my own compilation, but I see that vendors have been pushing out their own versions lately... -s -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.0RC2 Released!
On 8/23/06, Derick Rethans [EMAIL PROTECTED] wrote: That tells you that you're using extensions from the wrong PHP version with your version of PHP. Yes, it took an exhaustive search of the hard drive to find the problem. Some software I installed, put a php5ts file in a folder that got added to the PATH. It was confusing for me since apache kept saying PHP 5.2.0RC2. The module was that version, but when loading php5ts it took some other one in preference to the one in the same folder. I hate windows. Oh, and by the way, it is MUCH faster. Anyhow, sorry to eat up bandwidth. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.0RC2 Released!
APC is not in the distro, nor is it up on spans (for 5.2). Is this on purpose because of changes in PHP 5.2? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
