Re: Re: [PHP-DEV] What should be in 5.3?
On Tue, 2007-08-28 at 17:46 -0400, Cristian Rodriguez wrote: > On 8/27/07, Andi Gutmans <[EMAIL PROTECTED]> wrote: > > I think we're still far away from a working garbage collector which is > > production quality. > > Im sure it has bugs, but last time I tested the "circular" repository > it was working really fine and the save of memory was really big ;-) Yes, but Andi is desperate to have at least something else than just unicode support in PHP 6. No worries, this will go in 5.3. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP-6 / Mac OS X
It's a shame that icu is generated with a lot of cruft and while it can be built in a static library (archive) format, it has linking issues because the build itself is a hack. It seems that icu is a difficult build for shared libraries (impossible for the average user) but shared libraries have less linking issues. I spent some time repackaging it as a libtool type build so I could generate proper shared libraries with runtime paths and proper filename convention that work and don't suffer the linking issues of the static libraries. To aid development, use and implementation for Darwin/Mac OS X I've generated a universal build (x86 and ppc) to avoid a lot of headaches, perhaps this can be made available through the php site? I can package as a tar.gz file or a Mac OS X specific installer (the later is probably preferred to prevent a faulty installation by un- taring in an improper location) or I could toss it if you feel it isn't worth the time/effort to aid development/use for Darwin/Mac OS X. One other note, it seems that the latest PHP-6 from CVS doesn't build, it generates a faulty configure script and API changes prevent all kinds of included extensions from building or generating a working binary. mysql is one example of an extension that refuses to build dumping errors from ext/mysqlnd (too many to list). I haven't taken the time to go through the current CVS code yet, I reverted to an older CVS I downloaded a little while back that seemed to build without major issues (SEE: http://daleenterprise.com/info.php) and with a couple of edits I managed to get several pecl extensions to build thus giving me something useable to run on a test platform. There seems to be an issue with "Registered PHP Streams", "Registered Stream Socket Transports" and "Registered Stream Filters" however it may just be cosmetic but something that also needs looking into. Even my own self extensions seem to work in PHP6 so using the basic php-5.2.x API seems to carry through without issues. (SEE: http://daleenterprise.com/amavis-stats/index.php? host=&span=monthly&refresh=0) I haven't processed the rar extension yet (I have a client who relies on it) so it's on my todo project list. I see that memcache isn't included, is it no longer supported/ required or is it safe to rework it for the API changes in PHP-6 (too- late, already done and testing)? I see lots of errors in the log about "phpinfo() [function.phpinfo]: charset `utf8' not supported, assuming iso-8859-1 in /www/localhost/ info.php", I do have /default_charset = "iso-8859-1"/ set but it doesn't seem to make any difference. -- BuildSmart PGP.sig Description: This is a digitally signed message part
RE: Re: [PHP-DEV] What should be in 5.3?
This is based on our experience with making changes in the memory manager (significantly smaller changes than this one) and how long it takes to stabilize them. Andi > -Original Message- > From: Jani Taskinen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 29, 2007 1:58 AM > To: Cristian Rodriguez > Cc: internals@lists.php.net > Subject: Re: Re: [PHP-DEV] What should be in 5.3? > > On Tue, 2007-08-28 at 17:46 -0400, Cristian Rodriguez wrote: > > On 8/27/07, Andi Gutmans <[EMAIL PROTECTED]> wrote: > > > I think we're still far away from a working garbage collector which > is > > > production quality. > > > > Im sure it has bugs, but last time I tested the "circular" repository > > it was working really fine and the save of memory was really big ;-) > > Yes, but Andi is desperate to have at least something else than just > unicode support in PHP 6. No worries, this will go in 5.3. > > --Jani > > -- > 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] self:: or parent:: in an inherited class property declaration
Hi all, There has been some discussion on this list about late static binding and the 'self' & 'parent' keywords. I'm looking to understand the meaning of self:: and parent:: when used in the declaration of an inherited class property or constant. Based on discussions here and on comments to bugs like http://bugs.php.net/bug.php?id=30934, my understanding is that self:: should be bound statically at compile time. Therefore, in the example below, I would naively assume that self:: would always refer to class A. However, this is not the case. It seems that at compile time, the engine flags class properties/constants that depend on class constants. They are then subject to a one-off re-evaluation at execution time. The flagging is done by setting the zval 'type' field to IS_CONSTANT, IS_CONSTANT_ARRAY or IS_CONSTANT_INDEX. The re-evaluation is done in zend_update_class_constants(). When self:: is involved, the result of this re-evaluation is not always intuitive imho, and appears to contradict the idea that self:: is bound at compile time. See this test case for an illustration: http://pastebin.com/f1d93fb2e To summarize the behaviour exhibited by that test case: 1. An inherited static property's value depends on the order in which classes are touched at execution time. The meaning of 'self' is fixed, but depends on the scope in which zend_update_class_constants() is first executed. Removing line 15 changes the outcome of the test. 2. An inherited instance property's value depends on the instantiated class. When accessing the inherited property through an instance of A, 'self' is taken to mean A. When accessing it through an instance of B, 'self' is taken to mean 'B'. Presumably, this is because the property is propagated to the subclass before its default value is evaluated. 3. Similarly to 2, an inherited constant's value depends on how it is accessed. When accessing A::INHERITED_CONST, 'self' is taken to mean A; when accessing B::INHERITED_CONST, 'self' is taken to mean B. Is this as expected? I would argue that at least point 1 is a bug, but would appreciate opinions before I investigate further. (The exact same issues apply when using parent::. See this testcase: http://pastebin.com/f249a0e8c ) Regards, Robin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
Andi Gutmans schrieb: > This is based on our experience with making changes in the memory > manager (significantly smaller changes than this one) and how long it > takes to stabilize them. Then we should make sure that the garbage collector goes into HEAD ASAP, should we not? -- 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
RE: Re: [PHP-DEV] What should be in 5.3?
Sebastian, Just so you guys don't get the wrong idea, I have a garbage collector book sitting on my shelf which I bought 2-3 years ago as I was thinking of implementing this. Unfortunately I hit some issues and edge cases and didn't have enough time to spend on this. So I'm definitely not against a garbage collector. It's something I think would be very good for PHP even if it were optional. I do think though that we need an opportunity to review it, test it & benchmark it. Again, whoever has done work in his life on memory managers knows how sensitive they are. David, do you have a patch against PHP 5.2? For some reason I don't think I got the updated patch although Derick said you sent it out. Thanks, Andi > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann > Sent: Wednesday, August 29, 2007 8:06 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] What should be in 5.3? > > Andi Gutmans schrieb: > > This is based on our experience with making changes in the memory > > manager (significantly smaller changes than this one) and how long it > > takes to stabilize them. > > Then we should make sure that the garbage collector goes into HEAD > ASAP, > should we not? > > -- > 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] Testing math functions
Pierre wrote: On 8/23/07, Zoe Slattery <[EMAIL PROTECTED]> wrote: Hi - I've writing a few tests for the math extension and have a question about floating point precision. Here's a small example: --TEST-- Test return type and value for expected input sin() --INI-- precision = 14 --FILE-- --EXPECT-- sin 360 = float(-2.4492127076448E-16) Is it right to test for an exact number in this way? I was slightly suprised that I got the same number from Windows and Linux (maybe I shouldn't be). If not, I could write the test above to check that sin 360 is zero plus/minus some small number - but how small? It really depends on the architecture. Using a precision of 10 should put you on the safe side, at least for the common architecture (intel, amd and ppc). Yes - you are right thanks. I'm currently testing that the answer is within +/- 1.0E-10 of what I expect - that works on the processor architectures that I have access to. I guess I'll find out what happens on the others wheh I check the test cases in :-). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
Andi Gutmans schrieb: > Sebastian, Andi, > I do think though that we need an opportunity to review it, test it & > benchmark it. and this is exactly what I want to faciliate with having David's code merged into HEAD: exposing it to more people for increased testing. David developed his garbage collector in a CVS branch that was copied from PHP_5_2 back when he started. To make the patch smaller, easier to read, and the code review easier I suggest that all his code changes that change direct manipulations of reference counters to the use of the respective macros are committed - they make sense in any case. Cheers, Sebastian -- 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
Re: [PHP-DEV] Testing math functions
Richard Lynch wrote: On Thu, August 23, 2007 10:28 am, Zoe Slattery wrote: Hi - I've writing a few tests for the math extension and have a question about floating point precision. Here's a small example: --TEST-- Test return type and value for expected input sin() --INI-- precision = 14 --FILE-- --EXPECT-- sin 360 = float(-2.4492127076448E-16) Is it right to test for an exact number in this way? I was slightly suprised that I got the same number from Windows and Linux (maybe I shouldn't be). If not, I could write the test above to check that sin 360 is zero plus/minus some small number - but how small? Seems to me that if 'precision' setting is supposed to affect the output of your calculations, then you should, in theory, be able to rely on 14 decimal places, no?... Actually that isn't what "precision=14" does. Precision=14 will just print out the first 14 digits of the answer ignoring leading zeros. So when I change the ini setting to precision=3, the result I get for sin(360) is -2.45E-16, this doesn't help if the processor rounding error is > 1.0 E-16 say. I realize that's an over-simplistic answer, perhaps, and I thought the precision only applied to BC_MATH and/or GMP calculations. I'm sorry - I don't know enough about BC_MATH or GMP to comment. I'd be surprised if it was ALWAYS right for every OS, and I strongly suspect it's going to fail on 64-bit hardware big-time. As Piere says - and I just verified by using a few different processors - the answer is processor dependent. I guess the first question I have is "What precisely are you testing?" The 'precision' setting? Nope :-) Or just that sin(2 * M_PI) is kinda sorta close to 0? Yes - the most simple test of sin() or cos() functions is that they should give the expected result for known values. If you just want "close to 0" then double the answer you are getting now, and call that "close enough" :-) Well - maybe. After trying a few different processors a reasonable thing to do seems to be to check that the answer of a floating point calculation is within "plus or minus 1.0E-10" of the expected result. This feels a bit arbitrary - but there doesn't seems to be a better solution (except maybe a lot of research into allowable rounding errors from each sort of processor technology and I don't think this particular case warrants that) If you think 'precision' is supposed to affect it and guarantee 14 decimal places of precision, then 1.0E-14 to 1.0E14 should be your range, no? See above -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
Hi Andi, Andi Gutmans wrote: > Hi all, > >>From my point of view I think we can make a really good PHP 5.3 release > pretty quickly as long as we are careful about the scope. There's a lot > of good work which is low risk which we can easily roll into it. There > are high risk items like garbage collection etc. which I think we should > continue working on, etc. but target them more towards PHP 6. Adding > such features into a PHP 5.3 branch wouldn't allow us to release that > for a long time. I think schedule wise it's not unreasonable to do a > pretty feature rich PHP 5.3 beta in November and release in January. I > prefer the release-early, release-often mantra and that'll require us to > somewhat be careful about the scope and high risk items. > > The following are some suggestions we (Dmitry, Stas and I) have re: > items we had on our lists. We divided them into what we think are > must-haves (i.e. don't release without), should-haves (we should try to > get these in but they wouldn't be show stoppers for release), and nice > to-haves (low priority). > > Must have: > These are ones that we'd really like to be in 5.3 and think should delay > 5.3 release if they aren't ready. >1. ICU extension >2. OpenSSL modifications for OpenID >3. Dynamic class access ($class::method) >4. (binary) operator which is the same as (string) >5. remove --enable-fastcgi and family, always enable them >6. __callStatic & friends >7. remove warning for var > > Should have: > These are ones that we'd like to be in 5.3, but if there are problems > with them we are ready to go without them and catch up in 5.3.x, 5.4, > etc. >1. Unicode extension (normalization, character properties, etc.) >2. Late static binding >3. Namespaces (still needs maturing so that will be the main factor > for deciding if in or out) >4. Make memory manager pluggable per-request (simple patch) >5. Synchronize all OO module docs to look the same (PHPDOC team) >6. remove undocumented support for strings in list($a,$b) = "ab" >7. Move arg_info and other C constants from .data to .text (or > .rdata) segment >8. Non-parsed heredocs (nowdocs) > > Nice to have: > These are ones that we'd like to have in 5.3, but are not important > enough to spend energy on before first two groups are achieved (unless > of course somebody has a good working implementation). > >1. cookie2 support >2. stat cache for windows/unix >3. mysqlnd speaking of mysqlnd its state is beta. No new features, stabilizing. Currently when running in unicode mode there are about 714 pending execution. There are experimental functions in mysqli, which are skipped for testing. The aim has been always not to lag behind mysqli/libmysql and it's true. Actually mysqli/libmysql lags behing mysqli/mysqlnd as libmysql gets bug-fixes quite slower than mysqlnd does. mysql, mysqli and mysqlnd have gcov level above 88%, as far as I recall. The average for PHP is somewhere above 50%. JFYI, Ulf blogged lately on memory consumption and tuning of mysqlnd. Pretty long, but very good blog entry. We continue to identify bottlenecks and optimize mysqlnd. http://blog.ulf-wendel.de/?p=157 >4. goto >5. __construct in interfaces >6. Compiled functions (CFs) and classes in PHP >7. Allow parser to evaluate static expressions (-1, 2+2) in > compile-time (it won't work with constants (X+1)) > > Our 2 cents. > Andi > >> -Original Message- >> From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] >> Sent: Monday, August 27, 2007 2:30 AM >> To: PHP Developers Mailing List >> Subject: [PHP-DEV] What should be in 5.3? >> >> Hi, >> >> In the spirit of forwards compabitility I think the 5.3 release will > we >> very important regardless if we keep or remove the unicode switch in >> PHP6. From my POV 5.1 and 5.2 have mainly covered stability and >> performance improvements on top of the addition of several important >> extensions like PDO, Json etc. >> >> In terms of changes to the actual language the main thing that sticks >> in >> my head where things like E_STRICT and is_a vs. instanceOf. So now > with >> 5.3 we might want to look ahead towards PHP6 and make sure that we add >> whatever makes sense to have in 5.x that will ease the life for people >> writing forward compatible code for PHP6. It might also be a chance to >> revisit the question of how we want to approach strictness and >> deprecation. >> >> Forward compatibility: >> - binary cast >> - namespaces >> - ... >> >> Strictness: >> - What is our philisophy, is OO more strict than procedural or is > there >> no such differntiation? I remember the discussions about dynamic > member >> variables, number incrementing throwing notices inconsistently, >> signature rewriting. I fear I am opening a can of worms with this one. >> Although I disagree with the bulk of the decisions on this topic in > the >> past I am not trying to reopen the discussions, I just hope to get a >>
Re: [PHP-DEV] What should be in 5.3?
Then we should make sure that the garbage collector goes into HEAD ASAP, should we not? Does anybody uses HEAD in production on a bunch of moderate-to-heavily loaded sites? If not, how does it matter if the patch sits in HEAD or not, one that wishes to test it can do that. I'm not against GC (unless it's slow :) but I don't see why putting it into HEAD matters so much. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
Cristian Rodriguez wrote: > On 8/27/07, Andi Gutmans <[EMAIL PROTECTED]> wrote: >> I think we're still far away from a working garbage collector which is >> production quality. > > > Im sure it has bugs, but last time I tested the "circular" repository > it was working really fine and the save of memory was really big ;-) What sort of script did you save a lot of memory on? It takes some very specific code for you to see noticable savings with this. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
On 8/29/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > > Then we should make sure that the garbage collector goes into HEAD ASAP, > > should we not? > > Does anybody uses HEAD in production on a bunch of moderate-to-heavily > loaded sites? If not, how does it matter if the patch sits in HEAD or > not, one that wishes to test it can do that. > > I'm not against GC (unless it's slow :) but I don't see why putting it > into HEAD matters so much. HEAD is for _development. If we loose the development branch, I cannot imagine any sane to get things done, to get things in nice way :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
On 8/29/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > What sort of script did you save a lot of memory on? It takes some very > specific code for you to see noticable savings with this. I used very specific code otherwise there is no way to test if the particular enhacement work ;) I also used average and big apps in order to check if there was some regression, so far, no problem detected.( note that I did not measure speed, because I care 99% about proper behaviuor and 1% about speed) -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 - rar extension
On 8/30/07, BuildSmart <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On Aug 29, 2007, at 23:15:26, BuildSmart wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > I've fixed the rar extension, was a no-brainer, a one-line change,
> > not worthy of a patch file.
> >
> > @ -628,7 +628,7 @
> > /* {{{ rar_functions[]
> > *
> > */
> > - -function_entry rar_functions[] = {
> > +zend_function_entry rar_functions[] = {
> > PHP_FE(rar_open,NULL)
> > PHP_FE(rar_list,NULL)
> > PHP_FE(rar_entry_get, NULL)
> >
> > - -- BuildSmart
>
> Spoke too soon, while it builds with wanring it doesn't function
> properly and segfaults so I need to look at it a little closer.
Tony reads this list however I would suggest to use the right place to
post patch or report bugs:
http://pecl.php.net/package/rar to report a bug for the rar package.
http://pecl.php.net/support.php for the pecl-dev mailing list
Using the issues tracker will ensure that your patch will not get lost.
Cheers,
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Constants in namesapces
Hi Richard, "const" is usefull to declare "compile-time" constants in current scope (class or namespace). The syntax is the same. It is not allowed to use functions and variables in such declarations (this ability was proposed but then it was removed before commit). define() is a runtime function that allows declaring constant at run-time. Of course this function defines constants in global scope. Thanks. Dmitry. > -Original Message- > From: Richard Lynch [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 26, 2007 7:50 AM > To: Dmitry Stogov > Cc: 'PHP Internals List' > Subject: RE: [PHP-DEV] Constants in namesapces > > > On Wed, August 22, 2007 8:03 am, Dmitry Stogov wrote: > > You can have "const" outside namespaces but they are not real > > compile-time constants. > > They are set during execution in the same way as define() does. > > > > > const DIR = dirname(__FILE__); > > echo DIR; > > ?> > > You do realize this is going to engender a few zillion > threads on PHP-General benchmarking the two and endless > arguments about which is faster/better... > >const DIR = dirname(__FILE__); > define(DIR, dirname(__FILE__); > ?> > > I personally find it kinda silly to have TWO syntaxes for > defining constants in the global space, one of which looks > like a declarative statement in C, which will lead to a whole > new swath of arguments about what is "better" > > Why is 'define' any different than 'class' or 'function'? > > Seems to me that if you want these namespace thingies that > badly, then 'define' should follow the same rules as any > other declarative keyword. > > If you 'define' something in the namespace, it's in the namespace. > > If you want global scope, 'define' it outside a namespace and > be done with it. > > Seems to me you're just complicating things with no > real-world need here... > > What are your real-world "I need this because..." code samples? > > -- > Some people have a "gift" link here. > Know what I want? > I want you to buy a CD from some indie artist. > http://cdbaby.com/browse/from/lynch > Yeah, I get a buck. So? > > -- > 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
