Re: [PHP-DEV] PHP 5.1 branched!
On Tue, 9 Aug 2005, Sebastian Bergmann wrote: > Andi Gutmans schrieb: > > I just branched off PHP 5.1 (PHP_5_1). > > Does that mean that PHP_5_1 is in feature-freeze or are changes like > the one Derick proposed (making type hint violations throw an exception > instead of raising a fatal error) still possible for PHP 5.1? I've no intentation of putting that in PHP 5.1 myself just yet. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property Overloading RFC
On Mon, 8 Aug 2005, Andrei Zmievski wrote: > On Aug 4, 2005, at 12:09 AM, Derick Rethans wrote: > > > Then you don't do it - it's not a requirement... just an optional thing > > (and ofcourse you can't do the __have_prop() thing then that you > > suggested below. > > Why not? _have_prop() should be able to return true if the class does handle > one of those 1000 properties. They don't need to be declared. Ah,you meant that __have_prop() should always return the full array of things that are supported. That is fine, as long as we can have this generated from the "abstract" properties that people declared (so that they can be documented properly too). > > Works for me, but it needs to be able to called statically (::) and > > dynamically (->). > > Shouldn't be a problem, should it? Nope. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Property Overloading RFC
On Mon, 8 Aug 2005, Justin Hannus wrote: > The way ActionScript 2.0 solves this is with set and get keywords on function > declarations. Any class can contain as many setter/getters as they need,. > Since we dont want to introduce any new keywords how about something similar > with __set and __get? [...] > To allow for BC, if there is no identifier after the __set/__get then the > existing rules apply. This is all way to complex. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Tue, 9 Aug 2005, Sebastian Bergmann wrote: > Derick Rethans schrieb: > > I prefer not to comment on that :) > > I might have something to do with that, but I am not sure. You've nothing to do with that. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, 09 Aug 2005 14:31:08 +0800
[EMAIL PROTECTED] (Alan Knowles) wrote:
> On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
> > You are wrong because __autoload() *is* called and you can load
> > the class on the-fly. The only problem is if the class does not
> > exist in your code base, in which case, your application should
> > blow up!
>
> The basic point is that is_a() provided negative testing of
> non-existant classes
> if (!is_a($obj, "SomeRarelyUsedClass")) {
>
> instance_of does not, and can not, at present.
>
> This technique is already frequently used to cope with lazy
> loaded code, which even with cached code compilers, is pretty
> damn efficient in a scripted language (less IO operations, less
> parsing, less memory...)
>
> It is not about the fact we 'can' load the class, but that we dont
> 'want' to load the class.. - it's a waste of resources, memory,
> cpu etc. just for the sake of CS perfection..
>
> Last time I looked PHP was about getting thing done efficiently,
> not about giving your university professor a woody... ;)
That's my point. The autoload magic (crap? :)) is not in cause here.
If you _test_ something, you do not expect the test operator to
abort your execution (fatal error).
Guys, you are just making PHP more compiled-like. It's a bad idea,
in my opinion.
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > This technique is already frequently used to cope with lazy > > loaded code, which even with cached code compilers, is pretty > > damn efficient in a scripted language (less IO operations, less > > parsing, less memory...) > > > > It is not about the fact we 'can' load the class, but that we dont > > 'want' to load the class.. - it's a waste of resources, memory, > > cpu etc. just for the sake of CS perfection.. > > > > Last time I looked PHP was about getting thing done efficiently, > > not about giving your university professor a woody... ;) > > That's my point. The autoload magic (crap? :)) is not in cause here. > If you _test_ something, you do not expect the test operator to > abort your execution (fatal error). But you're testing for something that you *know* that can not exist in your code base. That is a broken test, so it should throw a fatal error. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5 or 6.0
Now that we branched it's time to rename HEAD to something else than 5.1 in order to have different version numbers. Although the name PHP 5.5 was mentioned before, I do think we should call it PHP 6.0. As the Unicode support is quite a drastic change. Going with PHP 6.0 also allows us to be a little less strict with breaking BC in the cases where that might be useful for the Unicode support. I took the freedom to commit this change to CVS, as I needed already different version numbers for the different versions of PHP that I install locally. If discussion results that we need to rename it to something else, that's ofcourse perfectly fine. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
Alan Knowles wrote:
On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
You are wrong because __autoload() *is* called and you can load the class
on the-fly. The only problem is if the class does not exist in your code
base, in which case, your application should blow up!
The basic point is that is_a() provided negative testing of non-existant
classes
if (!is_a($obj, "SomeRarelyUsedClass")) {
instance_of does not, and can not, at present.
This technique is already frequently used to cope with lazy loaded code,
which even with cached code compilers, is pretty damn efficient in a
scripted language (less IO operations, less parsing, less memory...)
It is not about the fact we 'can' load the class, but that we dont
'want' to load the class.. - it's a waste of resources, memory, cpu etc.
just for the sake of CS perfection..
Last time I looked PHP was about getting thing done efficiently, not
about giving your university professor a woody... ;)
I agree with Alan. I guess lazy loading is the key here and __autoload()
to me is about being able to do just that. However if we trigger the
lazy loading mechanism all over the place, then that defeats the
purpose. However like I said the straighforward solution is to
underecate is_a() and leave instanceof as is.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
On Tue, 9 Aug 2005, Derick Rethans wrote: Now that we branched it's time to rename HEAD to something else than 5.1 in order to have different version numbers. Although the name PHP 5.5 was mentioned before, I do think we should call it PHP 6.0. As the Unicode support is quite a drastic change. Going with PHP 6.0 also allows us to be a little less strict with breaking BC in the cases where that might be useful for the Unicode support. +1 and can we now also drop PHP_5_0 branch? :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
Derick Rethans schrieb: > I do think we should call it PHP 6.0 +1 -- Sebastian Bergmann http://www.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] PHP 5.5 or 6.0
6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;) - David > -Original Message- > From: Derick Rethans [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 09, 2005 10:41 AM > To: PHP Developers Mailing List > Subject: [PHP-DEV] PHP 5.5 or 6.0 > > Now that we branched it's time to rename HEAD to something else than 5.1 > in order to have different version numbers. Although the name PHP 5.5 > was mentioned before, I do think we should call it PHP 6.0. As the > Unicode support is quite a drastic change. Going with PHP 6.0 also > allows us to be a little less strict with breaking BC in the cases where > that might be useful for the Unicode support. > > I took the freedom to commit this change to CVS, as I needed already > different version numbers for the different versions of PHP that I > install locally. If discussion results that we need to rename it to > something else, that's ofcourse perfectly fine. > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.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] PHP 5.5 or 6.0
Hi 6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;) Namespaces patch is a patch so it's fine for version 5.5, if you would ask me. I would see the unicode support as a bigger step forward. -- Yours, Weyert de Boer ([EMAIL PROTECTED]) innerfuse* http://www.innerfuse.biz/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
>
> > > This technique is already frequently used to cope with lazy
> > > loaded code, which even with cached code compilers, is pretty
> > > damn efficient in a scripted language (less IO operations,
> > > less parsing, less memory...)
> > >
> > > It is not about the fact we 'can' load the class, but that we
> > > dont 'want' to load the class.. - it's a waste of resources,
> > > memory, cpu etc. just for the sake of CS perfection..
> > >
> > > Last time I looked PHP was about getting thing done
> > > efficiently, not about giving your university professor a
> > > woody... ;)
> >
> > That's my point. The autoload magic (crap? :)) is not in cause
> > here. If you _test_ something, you do not expect the test
> > operator to abort your execution (fatal error).
>
> But you're testing for something that you *know* that can not
> exist in your code base. That is a broken test, so it should
> throw a fatal error.
function wrapperFoo($obj) {
if (is_a($obj, 'MyFoo') {
}
... other tests
}
worked before is_a was deprecated.
function wrapperFoo($obj) {
if ($obj instanceof MyFoo) {
}
}
Fatal error, if I _known_ that a class _cannot_ exist, I will not
test it then, but the thing is that I do _not_ know.
If I provide a library (ie, encoded), this library being used in an
unknown environment by unknown poeple, or if I have performance
requirement and I do not want to require/include a class if I do
not have to use it, then this test makes full sense. I fail to see
how hard is it to understand...
Derick, your post about type hinting talks about the exact same
problem, being able to work out fatal error or user mistakes.
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.5 or 6.0
I was just kidding. I too consider Unicode support a very drastic change that deserves a new major version number. I'd like to see Namespaces support in by then, too, though. I really think PHP needs it. These two "features" are the only things PHP needs desperately, but cannot deliver. - David > -Original Message- > From: Weyert de Boer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 09, 2005 11:55 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.5 or 6.0 > > Hi > > >6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;) > > > > > Namespaces patch is a patch so it's fine for version 5.5, if you would > ask me. > I would see the unicode support as a bigger step forward. > > -- > Yours, > > Weyert de Boer ([EMAIL PROTECTED]) > innerfuse* > > http://www.innerfuse.biz/ > > -- > 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 5.5 or 6.0
On Tue, 9 Aug 2005, Weyert de Boer wrote: > >6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;) > > Namespaces patch is a patch so it's fine for version 5.5, if you would > ask me. I would see the unicode support as a bigger step forward. I'm not sure what you guys are discussing here, but it's definitely not up to any non-contributor to decide which version number we pick. And making it dependable on whether some patch goes in or not doesn't make sense at all. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.5 or 6.0
On Tue, 9 Aug 2005 10:41:07 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > Now that we branched it's time to rename HEAD to something else > than 5.1 in order to have different version numbers. Although the > name PHP 5.5 was mentioned before, I do think we should call it > PHP 6.0. As the Unicode support is quite a drastic change. Going > with PHP 6.0 also allows us to be a little less strict with > breaking BC in the cases where that might be useful for the > Unicode support. > > I took the freedom to commit this change to CVS, as I needed > already different version numbers for the different versions of > PHP that I install locally. If discussion results that we need to > rename it to something else, that's ofcourse perfectly fine. I have no special oppinions on php 5.5 or 6.0. But I have some about what we will do in php 5.x (without unicode, namespace), and 6.0. I like to see once that we clearly and loudly define what we want in or not. So I may waste less time than before. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
MW>>to *load* a class for checking an object to be of a specific class MW>> MW>>- just because of the simple reason that the checked object can not MW>> be of *that* class, because it doesn't exist. I think, if we leave alone the implementation, there's nothing logically wrong to return false if we ask "is $foo instance of class Bar" and we don't know what Bar is - just because if we don't know Bar $foo is definitely not instance of it. Now the only problem I see here is if you type Bar when you intended to type Baz - but I'm not sure this warrants the fatal error. Also, autoloading a class is rather expensive operation in PHP (and loading it regualr way too, generally, if we consider all the library classes we might need), so IMHO the idea that instanceof may return (maybe with some warning/notice) false on unknown class doesn't look that bad to me. Though, then it would be inconsistent with typehinting, for example - which I feel _should_ error out if typehint requires unknown class. MW>>There could be a flag to let instanceof *not* die - MW>>a little less generic but more suited for the actual needs IMO. I don't like the idea of all kinds of flags changing language behaviour. This promotes incompatible coding and effectively forks language into a set of incompatible sub-languages. Not having any defined behaviour is much worse than having behaviour that somebody dislikes. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
Hi I'm not sure what you guys are discussing here, but it's definitely not up to any non-contributor to decide which version number we pick. And making it dependable on whether some patch goes in or not doesn't make sense at all. Such a kind way of response on your site, I won't even consider anymore to share my contribution. -- Yours, Weyert de Boer ([EMAIL PROTECTED]) innerfuse* http://www.innerfuse.biz/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
Hi Stanislav Malyshev, you wrote: > Now the only problem I see here is if you > type Bar when you intended to type Baz - but I'm not sure this warrants > the fatal error. Yes, unit tests could catch such issues. > MW>>There could be a flag to let instanceof *not* die - > MW>>a little less generic but more suited for the actual needs IMO. > > I don't like the idea of all kinds of flags changing language behaviour. > This promotes incompatible coding and effectively forks language into a > set of incompatible sub-languages. Not having any defined behaviour is > much worse than having behaviour that somebody dislikes. Uh no! I didn't mean an INI or runtime flag, i was talking about fetch_class - i.e. the internal implementation may flag if the operation should result in a fatal error. Regards, -- Michael - < mike(@)php.net > signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: RC1, instanceof?
Alan Knowles wrote:
> The basic point is that is_a() provided negative testing of non-existant
> classes
> if (!is_a($obj, "SomeRarelyUsedClass")) {
>
> instance_of does not, and can not, at present.
You can use `if (!($obj instanceof SomeRarelyUsedClass))` ;)
Why statement `$obj instanceof NotLoadedClass` can't evaluate as FALSE
if class not loaded (what with serialized objects?) because if class not
loaded, than object can't be instanceof this class, right?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
On Tue, 9 Aug 2005 12:03:28 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Tue, 9 Aug 2005, Weyert de Boer wrote: > > > >6.0 if the Namespaces patch makes it in, 5.5 with Unicode > > >only? ;) > > > > Namespaces patch is a patch so it's fine for version 5.5, if > > you would ask me. I would see the unicode support as a bigger > > step forward. > > I'm not sure what you guys are discussing here, but it's > definitely not up to any non-contributor to decide which version > number we pick. And making it dependable on whether some patch > goes in or not doesn't make sense at all. A minimum of respect does not cost anything. The author of this patch invest a lot of time in it. A major version increment can (always?) depend on what it will have in. It can be a patch, a new extension or a deep change like unicode. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
A minimum of respect does not cost anything. The author of this patch invest a lot of time in it. Oh well, one of the reasons why the patch for the parser won't be available, no faster parser for PHP. Neither the other stuff I was working on, will just use for in my own compiles. A major version increment can (always?) depend on what it will have in. It can be a patch, a new extension or a deep change like unicode. Regards, --Pierre -- Yours, Weyert de Boer ([EMAIL PROTECTED]) innerfuse* http://www.innerfuse.biz/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, 09 Aug 2005 13:24:56 +0300
[EMAIL PROTECTED] (Pasha Zubkov) wrote:
> Alan Knowles wrote:
> > The basic point is that is_a() provided negative testing of
> > non-existant classes
> > if (!is_a($obj, "SomeRarelyUsedClass")) {
> >
> > instance_of does not, and can not, at present.
>
> You can use `if (!($obj instanceof SomeRarelyUsedClass))` ;)
>
> Why statement `$obj instanceof NotLoadedClass` can't evaluate as
> FALSE if class not loaded (what with serialized objects?) because
> if class not loaded, than object can't be instanceof this class,
> right?
We do __not__ know that.
This test tries to figure that out, exactly that. So no, it must
not end to a fatal error.
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > But I have some about what we will do in php 5.x (without unicode, > namespace), and 6.0. > > I like to see once that we clearly and loudly define what we want > in or not. So I may waste less time than before. I see it as: 4.4 - no new features, no new additions. Just bugfixes. 5.1 - no new major features, just smaller additions. 6.0 - brand new experimental stuff. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
On Tue, 9 Aug 2005 12:47:50 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > > But I have some about what we will do in php 5.x (without > > unicode, namespace), and 6.0. > > > > I like to see once that we clearly and loudly define what we > > want in or not. So I may waste less time than before. > > I see it as: > 4.4 - no new features, no new additions. Just bugfixes. > 5.1 - no new major features, just smaller additions. > 6.0 - brand new experimental stuff. That sounds basically good to me. My small thoughts: 5.1.x - bug fixes _only_ 5.x - small additions (in my case, gd updates and merge, xmlwriter) 6.0 - to define, for now we have two candidates, unicode for sure, namespace to be discussed/approved/ whatever Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PHP 5.5 or 6.0
> 6.0 - to define, for now we have two candidates, > unicode for sure, namespace to be discussed/approved/ > whatever How 'bout PIMP for 6.0, Pierre? *hint hint* ;) - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > On Tue, 9 Aug 2005 12:47:50 +0200 (CEST) > [EMAIL PROTECTED] (Derick Rethans) wrote: > > > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > > > > But I have some about what we will do in php 5.x (without > > > unicode, namespace), and 6.0. > > > > > > I like to see once that we clearly and loudly define what we > > > want in or not. So I may waste less time than before. > > > > I see it as: > > 4.4 - no new features, no new additions. Just bugfixes. > > 5.1 - no new major features, just smaller additions. > > 6.0 - brand new experimental stuff. > > That sounds basically good to me. > > My small thoughts: > > 5.1.x - bug fixes _only_ > 5.x - small additions (in my case, gd updates and merge, > xmlwriter) I don't think we should be going with another 5.x release as we've plenty of stuff to do for 6.0, gd updates/merges should go to 5.1.x too. If we want to include xmlwriter at all in the default distribution is another discussion. (So that should go to another thread IMO). regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
On Tue, 9 Aug 2005 13:02:47 +0200 (CEST) Derick Rethans <[EMAIL PROTECTED]> wrote: > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > > On Tue, 9 Aug 2005 12:47:50 +0200 (CEST) > > [EMAIL PROTECTED] (Derick Rethans) wrote: > > > > > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > > > > > > But I have some about what we will do in php 5.x (without > > > > unicode, namespace), and 6.0. > > > > > > > > I like to see once that we clearly and loudly define what we > > > > want in or not. So I may waste less time than before. > > > > > > I see it as: > > > 4.4 - no new features, no new additions. Just bugfixes. > > > 5.1 - no new major features, just smaller additions. > > > 6.0 - brand new experimental stuff. > > > > That sounds basically good to me. > > > > My small thoughts: > > > > 5.1.x - bug fixes _only_ > > 5.x - small additions (in my case, gd updates and merge, > > xmlwriter) > > I don't think we should be going with another 5.x release as > we've plenty of stuff to do for 6.0, gd updates/merges should go > to 5.1.x too. I'm not sure that a merge fits in 5.1.x, the amount of changes are relatively big and are far away from bug fixes. > If we want to include xmlwriter at all in the > default distribution is another discussion. (So that should go to > another thread IMO). The discussion is already done and we agreed. It did not make it in 5.1 for various reasons. I only stated two of my todos here. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote: > > If we want to include xmlwriter at all in the > > default distribution is another discussion. (So that should go to > > another thread IMO). > > The discussion is already done and we agreed. It did not make it in > 5.1 for various reasons. I only stated two of my todos here. I'd like to see some thread on that, as I definitely never saw anything like that here. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/calendar - New test scripts
Sorry, I forgot to add subject line to the old mail. On Mon, 08 Aug 2005 23:56:24 -0700, "Rathna N" <[EMAIL PROTECTED]> said: > Hi All, > this is first my post to this list. > I'm interested to do QA related contributions to PHP. > > Pls do find the test scripts for Calendar extension at below links, > > http://www.geocities.com/rs81099/calendartest.zip > - contains the testscripts > > http://www.geocities.com/rs81099/calendarTestOutput.txt > - contains the test report on SUSE LINUX 9.2.1 > > I request you to review and commit the same, (If u r ok with the > scripts). > > Pls do pass on if u have any feedback to improve the quality of > TestScripts. > > Regards, > Rathna. > -- > Rathna N > [EMAIL PROTECTED] > > -- > http://www.fastmail.fm - The professional email service > -- Rathna N [EMAIL PROTECTED] -- http://www.fastmail.fm - I mean, what is it about a decent email service? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/calendar - New test scripts
On Tue, 9 Aug 2005, Rathna N wrote: > Sorry, I forgot to add subject line to the old mail. the [EMAIL PROTECTED] list would be the best list for this subject. As for the tests, it would be nice if you could provide a unified diff against CVS's HEAD. That's much easier than have to download a .zip file - we can more easily check the test cases then. Some points on the tests: - please always use lower case filenames for the tests. - as --TEST-- name, please just use the name of the function, such as "jdtojulian()" (without any other description) - try always to cover edge cases in your tests. (For gregorian times, it makes sense to check what it does around the beginning of the gregorian calendar for example). - prefer var_dump() over print_r(). - Always use the ISO 8601 format for outputting date (if you're formatting them yourself). See easter_date.phpt f.e. - In easter_date.phpt, you'll have to check way more years - just testing 3 is not enough. - There is no --DESCRIPTION-- field as you used in GregorianToJD.phpt. - Always use http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/calendar - New test scripts
thank you for the response. I will incorporate the feedback and send the updated ones. Regards, Rathna. On Tue, 9 Aug 2005 13:45:06 +0200 (CEST), "Derick Rethans" <[EMAIL PROTECTED]> said: > On Tue, 9 Aug 2005, Rathna N wrote: > > > Sorry, I forgot to add subject line to the old mail. > > the [EMAIL PROTECTED] list would be the best list for this subject. > As for the tests, it would be nice if you could provide a unified diff > against CVS's HEAD. That's much easier than have to download a .zip file > - we can more easily check the test cases then. > > Some points on the tests: > - please always use lower case filenames for the tests. > - as --TEST-- name, please just use the name of the function, such as > "jdtojulian()" (without any other description) > - try always to cover edge cases in your tests. (For gregorian times, it > makes sense to check what it does around the beginning of the > gregorian calendar for example). > - prefer var_dump() over print_r(). > - Always use the ISO 8601 format for outputting date (if you're > formatting them yourself). See easter_date.phpt f.e. > - In easter_date.phpt, you'll have to check way more years - just > testing 3 is not enough. > - There is no --DESCRIPTION-- field as you used in GregorianToJD.phpt. > - Always use - Please stick to the PEAR coding standards in your tests. > > And thanks for picking this up! But perhaps I can suggest to start with > other more used extensions? Most of our string and array functions don't > have enough testcases either. > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org -- Rathna N [EMAIL PROTECTED] -- http://www.fastmail.fm - mmm... Fastmail... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: internal class' static properties
As already mentioned earlier, there does not seem to be any extension or core code using static properties for internal classes. I'd like to request a change in their behaviour/implementation. Currently static properties of internal classes are allocated persitently which limits their usage and has odd sideaffects. AFAICS they are declared at MINIT and initialized once, also at MINIT. Now, if they become modified (running as a module) they'll "leak" from one request to another. Therefore I'd suggest changing that so that they'll be initialized and destructed for each request, which means that there will need to be some form of hooks, which AFAICS also allows to have streams or arrays (i.e. complex types) as static properties just like in userland. PS: It seems that there's class constant API missing too. Regards, -- Michael - < mike(@)php.net > signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] PHP 5.5 or 6.0
Quoting Weyert de Boer <[EMAIL PROTECTED]>: Hi I'm not sure what you guys are discussing here, but it's definitely not up to any non-contributor to decide which version number we pick. And making it dependable on whether some patch goes in or not doesn't make sense at all. Such a kind way of response on your site, I won't even consider anymore to share my contribution. Don't get offended, Derick is a nice guy :) -- Yours, Weyert de Boer ([EMAIL PROTECTED]) innerfuse* Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: internal class' static properties
I wrote: > Therefore I'd suggest changing that so that they'll be > initialized and destructed for each request, which means > that there will need to be some form of hooks, which Let me change that part... :) There's no need for any "hooks" as there's already RINIT() and RSHUTDOWN(), so I guess all I'm proposing is not handling static properties of internal classes persitently. Regards, -- Michael - < mike(@)php.net > signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
Derick Rethans wrote: > I see it as: > 4.4 - no new features, no new additions. Just bugfixes. > 5.1 - no new major features, just smaller additions. > 6.0 - brand new experimental stuff. This breakdown looks good, although it'd be nice to quantify just what kind of "smaller additions" are acceptable for 5.1 branch. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] drastic memory consumption with a sequence of exceptions
I've noticed that in a script of mine, memory consumption can explode quite
drastically when Exceptions are thrown, opposed to very normal memory
consumption when exceptions are not thrown.
This is the idea:
process();
}
catch (Exception $e)
{
$errors[] = $e->getMessage();
}
}
?>
When exceptions are not thrown, memory consumption is normal. The method's
local vars are freed and not much more memory is used in the 50th pass
compared to the 1st. But when exceptions are thrown, memory consumption
increases quite a bit every pass. In the end (within the 60 passes of my
loop) over 8 MB's are used.
Of course, I can unset a lot of data before throwing exceptions to free up
memory and the problem will be solved. But it would be nicer if the cleanup
would happen as an exception is thrown.
Can this be considered a bug or is this behavior known and accepted?
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: drastic memory consumption with a sequence of exceptions
It is very likely that this has something to do with DOM. It's a huge piece
of code though, making it hard to test where the problem really lies.
""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> I've noticed that in a script of mine, memory consumption can explode
quite
> drastically when Exceptions are thrown, opposed to very normal memory
> consumption when exceptions are not thrown.
>
> This is the idea:
>
> class Obj
> {
> function process($i)
> {
> // do a lot of stuff, occupy a lot of memory within the scope of this
> function
> throw new Exception("error");
> }
> }
>
> $obj = new Obj();
> $errors = array();
>
> for ($i=0; $i < 60; $i++)
> {
> try
> {
> $obj->process();
> }
> catch (Exception $e)
> {
> $errors[] = $e->getMessage();
> }
> }
> ?>
>
> When exceptions are not thrown, memory consumption is normal. The method's
> local vars are freed and not much more memory is used in the 50th pass
> compared to the 1st. But when exceptions are thrown, memory consumption
> increases quite a bit every pass. In the end (within the 60 passes of my
> loop) over 8 MB's are used.
>
> Of course, I can unset a lot of data before throwing exceptions to free up
> memory and the problem will be solved. But it would be nicer if the
cleanup
> would happen as an exception is thrown.
>
> Can this be considered a bug or is this behavior known and accepted?
>
> Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: drastic memory consumption with a sequence of exceptions
The problem occurs in this particular situation:
public function process($data)
{
$largeResultSet = $this->xmlParser->parseString($data);
foreach ($largeResultSet as &$item)
{
throw new Exception("error");
}
}
It only happens if the exception is thrown from within the foreach(). It
seems the $largeResultSet is not freed in this case. Using the foreach by
reference or not (&$item or $item) does not make a difference.
Ron
""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> It is very likely that this has something to do with DOM. It's a huge
piece
> of code though, making it hard to test where the problem really lies.
>
> ""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
> news:[EMAIL PROTECTED]
> > I've noticed that in a script of mine, memory consumption can explode
> quite
> > drastically when Exceptions are thrown, opposed to very normal memory
> > consumption when exceptions are not thrown.
> >
> > This is the idea:
> >
> > > class Obj
> > {
> > function process($i)
> > {
> > // do a lot of stuff, occupy a lot of memory within the scope of
this
> > function
> > throw new Exception("error");
> > }
> > }
> >
> > $obj = new Obj();
> > $errors = array();
> >
> > for ($i=0; $i < 60; $i++)
> > {
> > try
> > {
> > $obj->process();
> > }
> > catch (Exception $e)
> > {
> > $errors[] = $e->getMessage();
> > }
> > }
> > ?>
> >
> > When exceptions are not thrown, memory consumption is normal. The
method's
> > local vars are freed and not much more memory is used in the 50th pass
> > compared to the 1st. But when exceptions are thrown, memory consumption
> > increases quite a bit every pass. In the end (within the 60 passes of my
> > loop) over 8 MB's are used.
> >
> > Of course, I can unset a lot of data before throwing exceptions to free
up
> > memory and the problem will be solved. But it would be nicer if the
> cleanup
> > would happen as an exception is thrown.
> >
> > Can this be considered a bug or is this behavior known and accepted?
> >
> > Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, Aug 09, 2005 at 02:31:08PM +0800, Alan Knowles wrote: > > It is not about the fact we 'can' load the class, but that we dont > 'want' to load the class.. - it's a waste of resources, memory, cpu etc. > just for the sake of CS perfection.. Hear, hear! --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property Overloading RFC
On Aug 9, 2005, at 12:18 AM, Derick Rethans wrote: Ah,you meant that __have_prop() should always return the full array of things that are supported. That is fine, as long as we can have this generated from the "abstract" properties that people declared (so that they can be documented properly too). No, I meant that prototype for _have_prop() would be: bool function _have_prop(string $propname) _have_prop() should only care about "virtual" properties anyway. You pass it a property name, it tells you whether it is a virtual one or not. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 branched!
Andi et al, I am hoping to finish rough draft of HTTP input decoding today. I'd rather not merge in half-finished stuff. Besides that, do you think we need a write up on what has been changed in the core, new APIs, function upgrade guidelines, etc? Ping me on IM if you can. -Andrei On Aug 8, 2005, at 9:48 PM, Andi Gutmans wrote: Hi all, I just branched off PHP 5.1 (PHP_5_1). I will roll a tarball later on or tomorrow for RC1. Please from now on commit bug fixes to both PHP_5_1 and HEAD (and if critical, I suggest to do so with PHP_5_0 too in case we need to release another mini release). We should be able to kill it off once 5.1.0 is out (hopefully very soon). Andrei, Dmitry - You can start doing the merge. Please email internals@ with exactly which modules shouldn't be touched while you do this (it would include at least Zend/ & main/ but probably also some other stuff). Andi -- 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] Moving to PHP5.1 and Apache 2.2 next year, need help
Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and #2 can be accomplished, and that would at least be a good start. You are right about the libraries, but in time, even these may become thread safe (of course, likely not by anyone from the PHP-community). Why is this thread-safety such a taboo for many of the people here? Don't get me wrong, I know it can't be done in one go, but a start could be made, right? Perhaps that start could be made from PHP6 on? It doesn't have to be officially thread safe, because of all the libraries, but it could be thread-safer... Ron "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > steve roussey wrote: > > I have read and understand that there are a number of issues: > > > > 1. Problems with the Apache2 sapi > > 2. Problems with thread safety in the Zend Engine or PHP itself > > 3. Problems with thread-safety of modules > > You missed the most serious one. Thread safety problems in random > libraries you link in and we have absolutely no control over those. > > My stuff is far bigger and busier than yours, and I have absolutely no > intention to go threaded anytime soon. > > -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
I am not familiar with PIMP, but I would not get it in 6.0 until we have HOES (HTML Output Extension Server) complete. Then we can start on the client(s) for 6.1 :-). -- Jessie "David Zülke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 6.0 - to define, for now we have two candidates, > > unicode for sure, namespace to be discussed/approved/ > > whatever > > How 'bout PIMP for 6.0, Pierre? *hint hint* ;) > > - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to PHP5.1 and Apache 2.2 next year, need help
If we find thread safety problems in PHP we will fix them, of course. It's not like we ignore them. Same goes for extensions, except for those which are specifically designed to access libraries that show no signs of ever becoming thread safe. At the same time, you need to recognize that developers work on what interests them and what they personally have a need for. I can't speak for everyone, but a good number of the core developers lean towards the robustness of a multi-process architecture. Having separate memory spaces makes everything easier to debug and when something does go wrong it doesn't take down the whole server. These are both very compelling reasons to stick with this architecture. -Rasmus Ron Korving wrote: > Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and > #2 can be accomplished, and that would at least be a good start. You are > right about the libraries, but in time, even these may become thread safe > (of course, likely not by anyone from the PHP-community). Why is this > thread-safety such a taboo for many of the people here? Don't get me wrong, > I know it can't be done in one go, but a start could be made, right? Perhaps > that start could be made from PHP6 on? It doesn't have to be officially > thread safe, because of all the libraries, but it could be thread-safer... > > Ron > > > "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >>steve roussey wrote: >> >>>I have read and understand that there are a number of issues: >>> >>>1. Problems with the Apache2 sapi >>>2. Problems with thread safety in the Zend Engine or PHP itself >>>3. Problems with thread-safety of modules >> >>You missed the most serious one. Thread safety problems in random >>libraries you link in and we have absolutely no control over those. >> >>My stuff is far bigger and busier than yours, and I have absolutely no >>intention to go threaded anytime soon. >> >>-Rasmus > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to PHP5.1 and Apache 2.2 next year, need help
Hi Ron, On Tuesday 09 August 2005 19:09, Ron Korving wrote: > Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and > #2 can be accomplished, and that would at least be a good start. You are > right about the libraries, but in time, even these may become thread safe > (of course, likely not by anyone from the PHP-community). Why is this > thread-safety such a taboo for many of the people here? Don't get me wrong, > I know it can't be done in one go, but a start could be made, right? > Perhaps that start could be made from PHP6 on? It doesn't have to be > officially thread safe, because of all the libraries, but it could be > thread-safer... PHP itself is thread-safe. The problem is in the libraries. Rasmus once wrote a nice mail to this list about these problems: http://news.php.net/php.internals/10491 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
I think by "client(s)" you mean JOHNS (Justified Output with Heuristic Notifications Server). On Aug 9, 2005, at 11:14 AM, Jessie Hernandez wrote: I am not familiar with PIMP, but I would not get it in 6.0 until we have HOES (HTML Output Extension Server) complete. Then we can start on the client(s) for 6.1 :-). -- Jessie "David Zülke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] 6.0 - to define, for now we have two candidates, unicode for sure, namespace to be discussed/approved/ whatever How 'bout PIMP for 6.0, Pierre? *hint hint* ;) - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Darrell Brogdon [EMAIL PROTECTED] http://darrell.brogdon.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
Maybe a little late throwing my 2 cents in, but here they are anyway. If you're writing an app that can optionally use a component that is not present, there is nothing conceptually wrong with calling instanceof to determine if that support is present; PHP should not blow up. If the class is not loaded, then the object can't possibly be an instance of it, therefore the operator should return false. --Wez. On 8/9/05, Andi Gutmans <[EMAIL PROTECTED]> wrote: > You are wrong because __autoload() *is* called and you can load the class > on the-fly. The only problem is if the class does not exist in your code > base, in which case, your application should blow up! > > Andi > > At 07:44 AM 8/9/2005 +0200, Pierre-Alain Joye wrote: > >On Mon, 08 Aug 2005 14:43:25 -0700 > >[EMAIL PROTECTED] (Andi Gutmans) wrote: > > > > > I don't agree that instanceof on a class which doesn't exist > > > should work. It doesn't do so in other languages (or at least not > > > in Java/C++(dynamic_cast)) nor does it really seem to make a lot > > > of sense and be useful. Sounds more like an edge case you have > > > hit with some weird code which can probably be written > > > differently. > > > >You cannot compare PHP with Java and C++ in this case, sorry. They > >work differently for known reason (compiled being one). > > > >If you have a method, which could be a factory, or the behaviors > >depends on which object it gets, you have now 2 choices: > > > >- Accept to live with a possible fatal error > > > >- Include all single classes you are going to check, even if you > > will use none of them. > > > >The 3rd possibility, fix instanceof. > > > > > Today, fetching of classes in the language is very generic, and > > > they have to exist. I see very few cases where this would not be > > > true if you are writing a regular application. In those few cases > > > where you are doing something extremely weird, you can use > > > reflection to introspect an object. > > > >Agreed, that's fetch_class is not opportun for instanceof. My point > >is not about the fetch_class is done but the way instanceof works. > >Reflection is terribly overkilled for such a need, and slow. > > > > > There is no way this would be changed for RC1 (or PHP 5.1) > > > because it's a significant change which would affect many places > > > and not only instanceof. I personally think it shouldn't be > > > changed at all. If you're referencing classes/exceptions in your > > > code that don't exist, then something is very bogus with your > > > code. Don't use a NonExistantException if that could happen, use > > > Exception... > > > >Agreed here too, not related to instanceof though. > > > > > >--Pierre > > > >-- > >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
Re: [PHP-DEV] Re: RC1, instanceof?
On Aug 9, 2005, at 5:56 AM, Pierre-Alain Joye wrote:
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
This technique is already frequently used to cope with lazy
loaded code, which even with cached code compilers, is pretty
damn efficient in a scripted language (less IO operations,
less parsing, less memory...)
It is not about the fact we 'can' load the class, but that we
dont 'want' to load the class.. - it's a waste of resources,
memory, cpu etc. just for the sake of CS perfection..
Last time I looked PHP was about getting thing done
efficiently, not about giving your university professor a
woody... ;)
That's my point. The autoload magic (crap? :)) is not in cause
here. If you _test_ something, you do not expect the test
operator to abort your execution (fatal error).
But you're testing for something that you *know* that can not
exist in your code base. That is a broken test, so it should
throw a fatal error.
function wrapperFoo($obj) {
if (is_a($obj, 'MyFoo') {
}
... other tests
}
worked before is_a was deprecated.
function wrapperFoo($obj) {
if ($obj instanceof MyFoo) {
}
}
To duplicate the old semantic now you need to do:
if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
which is definitely uglier than
if(is_a($obj, 'MyFoo')) {}
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
On 8/9/05, Pierre-Alain Joye <[EMAIL PROTECTED]> wrote: > 5.x - small additions (in my case, gd updates and merge, > xmlwriter) This is what PECL is for. We're trying to move stuff out of the core so that these kinds of updates are easier for everyone to work on and use. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.5 or 6.0
> Now that we branched it's time to rename HEAD to something else than 5.1 > in order to have different version numbers. Although the name PHP 5.5 > was mentioned before, I do think we should call it PHP 6.0. As the > Unicode support is quite a drastic change. Going with PHP 6.0 also > allows us to be a little less strict with breaking BC in the cases where > that might be useful for the Unicode support. > +1 for 6.0 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
Bitch, where are my page views? -Andrei On Aug 9, 2005, at 10:26 AM, Darrell Brogdon wrote: I think by "client(s)" you mean JOHNS (Justified Output with Heuristic Notifications Server). On Aug 9, 2005, at 11:14 AM, Jessie Hernandez wrote: I am not familiar with PIMP, but I would not get it in 6.0 until we have HOES (HTML Output Extension Server) complete. Then we can start on the client(s) for 6.1 :-). -- Jessie "David Zülke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] 6.0 - to define, for now we have two candidates, unicode for sure, namespace to be discussed/approved/ whatever How 'bout PIMP for 6.0, Pierre? *hint hint* ;) - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Darrell Brogdon [EMAIL PROTECTED] http://darrell.brogdon.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: internal class' static properties
Hello Michael, Tuesday, August 9, 2005, 2:19:25 PM, you wrote: > I wrote: >> Therefore I'd suggest changing that so that they'll be >> initialized and destructed for each request, which means >> that there will need to be some form of hooks, which > Let me change that part... :) > There's no need for any "hooks" as there's already > RINIT() and RSHUTDOWN(), so I guess all I'm proposing > is not handling static properties of internal classes > persitently. class consts should be easy and we two times had a patch for that. And i definitively ask to support that since otherwise we flood our namespace, see pdo, spl and the amount of defines there. With a peep to pecl i see tons of more consts (especially in http). regarding static props the solution is to define another hash table in the class_entry that holdes the initial values for the static variables. During minit these would be copied to the used hash table, done. But even though the solution is pretty easy i do not know if we really want to support that. We have default properties and all that stuff already. Can't we simply check if default values for static properties wouldn't do the job and if there is something missing in that? Andi? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to PHP5.1 and Apache 2.2 next year, need help
On 8/8/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > > 3. Problems with thread-safety of modules > > You missed the most serious one. Thread safety problems in random > libraries you link in and we have absolutely no control over those. OK, I am confused. I always thought (an assumption with nothing to back it up, now that I think about it) that the core part of PHP was thread safe and that it was the third party libraries included from _extensions_ that were at issue. So if I used mysqli then it was at the mercy of the mysql library. So if the mysqli maintainer knew that that library was safe and their extension was safe then they could mark it as safe. All others would go through a single mutex, etc... But if PHP core uses a library and has no idea if it is safe or not (like glibc, though would run under such a system?) then I get your point. I hadn't considered it before. I suppose that is why MySQL statically links in such things that it knows works, not leaving anything to chance. I guess PHP's greatest strength is also its weakness, PHP can never realistically be thread safe and we'll all just deal with it. Really, it has never been an issue before. I'm not a flag waver for threads! I've been perfectly happy with PHP4 and Apache1. It is just the Keep-Alive and connection pooling issues would more easily work themselves out in a threaded environment. Its a clean solution (from the point of view of using PHP, developing that is a different issue). I suppose adding in layers to fix these issues is the best direction to take, like separate connection pooling software to databases and another separate application to the same in reverse with keep-alive (a proxy would work here). With both "bookends" running on the same server and using domain sockets to PHP, it should work fine and is no longer a subject for this list. :) > My stuff is far bigger and busier than yours I know my name can be easily traced to a website I own that only gets about 10M pv/day but I also work as a consultant for another that gets an order of magnitude more. So perhaps you do get more then them and get 1B pv/day and your dad can beat up my dad. Ug. Strike that. I'm just frustrated and stressed. (My own website doesn't even need the db connection pooling just yet. Though it could use Keep-Alive..) I'll leave this discussion only with this: I love PHP and appreciate what everyone has contributed over the years. Thanks! (And now I'll shut up.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to PHP5.1 and Apache 2.2 next year, need help
On Aug 9, 2005, at 3:12 PM, steve roussey wrote: On 8/8/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: 3. Problems with thread-safety of modules You missed the most serious one. Thread safety problems in random libraries you link in and we have absolutely no control over those. OK, I am confused. I always thought (an assumption with nothing to back it up, now that I think about it) that the core part of PHP was thread safe and that it was the third party libraries included from _extensions_ that were at issue. So if I used mysqli then it was at the mercy of the mysql library. So if the mysqli maintainer knew that that library was safe and their extension was safe then they could mark it as safe. All others would go through a single mutex, etc... But if PHP core uses a library and has no idea if it is safe or not (like glibc, though would run under such a system?) then I get your point. I hadn't considered it before. I suppose that is why MySQL statically links in such things that it knows works, not leaving anything to chance. This can affect you even if you're not statically linked. Dynamically loaded libraries run in your address space and have the same ability to mess you up as statically linked libraries. Otherwise your understanding is spot-on. Here there be dragons. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
Wez Furlong wrote: On 8/9/05, Pierre-Alain Joye <[EMAIL PROTECTED]> wrote: 5.x - small additions (in my case, gd updates and merge, xmlwriter) This is what PECL is for. We're trying to move stuff out of the core so that these kinds of updates are easier for everyone to work on and use. As a matter of fact why dont we take the chance of a new major version to take a novel approach. Lets decide what PHP should have by default, start off with an empty list of extensions and include all the necessary extensions from PECL that fulfill these needs (and put anything missing on the todo list for 6.1). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
I am not stubborn. I just think this has close to 0 use in real-life (or you're doing some weird coding). In any case, for the one in a million case, I think Reflection is good enough. Andi At 08:40 AM 8/9/2005 +0200, Michael Wallner wrote: Hi Andi Gutmans, you wrote: > You are wrong because __autoload() *is* called and you can load the > class on the-fly. The only problem is if the class does not exist in > your code base, in which case, your application should blow up! No insult intended, but this is just stubborn. You want to hear a good reason/argument, so the reason is that there is no reason - now please read slowly and thouroughly - to *load* a class for checking an object to be of a specific class - just because of the simple reason that the checked object can not be of *that* class, because it doesn't exist. So what if the mentioned generic way is too "generic"? There could be a flag to let instanceof *not* die - a little less generic but more suited for the actual needs IMO. It may be too late for 5.1 but it's *never* "too late" for future considerations. Regards, -- Michael - < mike(@)php.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
I think Unicode warrants a major version. I'd go with PHP 6 and aim to release it before Perl 6 :) From judging by a Perl 6 talk we attended at OSCON, that might actually be a realistic goal. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to PHP5.1 and Apache 2.2 next year, need help
On 8/9/05, steve roussey <[EMAIL PROTECTED]> wrote: > > My stuff is far bigger and busier than yours > > My spewing of stuff... I often write things to make me feel better and delete them before hitting send. Sort of stream of consciousness that I edit before sending. IRasmus, apologize for being an ass. -steve- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
Andi Gutmans wrote: I am not stubborn. I just think this has close to 0 use in real-life (or you're doing some weird coding). In any case, for the one in a million case, I think Reflection is good enough. I worded my example a bit wrong. I dont like people loading PEAR.php on demand. However I think the need is quite real. In PHP its quite natural to load code on demand and in sufficiently modular code its quite realistic that one piece of code will not know about what code was loaded and therefore use something like instanceof to determine what instance its dealing with. Anyways I think sufficient numbers of people have experessed that they would like this functionality which was provided by the deprecated is_a() method. So the decision to make seems to be if: 1) is_a() should simply be undeprecated 2) instanceOf be modified I am +1 on 1) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
My the way, the performance argument wouldn't work because even if this
would be supported, we'd have to first "try" and load the class to make
sure we can actually check the instanceof, and only if the class doesn't
load then we would return false. So you won't save that step of trying to
load the interface/class.
At 11:56 AM 8/9/2005 +0200, Pierre-Alain Joye wrote:
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
>
> > > This technique is already frequently used to cope with lazy
> > > loaded code, which even with cached code compilers, is pretty
> > > damn efficient in a scripted language (less IO operations,
> > > less parsing, less memory...)
> > >
> > > It is not about the fact we 'can' load the class, but that we
> > > dont 'want' to load the class.. - it's a waste of resources,
> > > memory, cpu etc. just for the sake of CS perfection..
> > >
> > > Last time I looked PHP was about getting thing done
> > > efficiently, not about giving your university professor a
> > > woody... ;)
> >
> > That's my point. The autoload magic (crap? :)) is not in cause
> > here. If you _test_ something, you do not expect the test
> > operator to abort your execution (fatal error).
>
> But you're testing for something that you *know* that can not
> exist in your code base. That is a broken test, so it should
> throw a fatal error.
function wrapperFoo($obj) {
if (is_a($obj, 'MyFoo') {
}
... other tests
}
worked before is_a was deprecated.
function wrapperFoo($obj) {
if ($obj instanceof MyFoo) {
}
}
Fatal error, if I _known_ that a class _cannot_ exist, I will not
test it then, but the thing is that I do _not_ know.
If I provide a library (ie, encoded), this library being used in an
unknown environment by unknown poeple, or if I have performance
requirement and I do not want to require/include a class if I do
not have to use it, then this test makes full sense. I fail to see
how hard is it to understand...
Derick, your post about type hinting talks about the exact same
problem, being able to work out fatal error or user mistakes.
--Pierre
--
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] Re: RFC: internal class' static properties
Hi Michael, I agree that this might be the right way to resolve the current issues. I mentioned it to Marcus at OSCON. Andi At 02:19 PM 8/9/2005 +0200, Michael Wallner wrote: I wrote: > Therefore I'd suggest changing that so that they'll be > initialized and destructed for each request, which means > that there will need to be some form of hooks, which Let me change that part... :) There's no need for any "hooks" as there's already RINIT() and RSHUTDOWN(), so I guess all I'm proposing is not handling static properties of internal classes persitently. Regards, -- Michael - < mike(@)php.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, 09 Aug 2005 12:29:45 -0700 Andi Gutmans <[EMAIL PROTECTED]> wrote: > we'd have to first "try" and load the class to make > sure we can actually check the instanceof Pardon me? :) As I said in my 2nd post about this topic, the problem (and only problem here) is that in the lexer, the right part of instanceof is class_reference_name (from memory for the exact name :), which corresponds to the normal class fetch, as in "new MyClass". This is the wrong part of instanceof. Its implementation does not try to load a class or to raise any single notice/error/warning. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5 or 6.0
Hi Ilia, I think it's hard to define ahead of time, but usually I prefer allowing non-BC breaking and non-infrastructure changes, for example, a new function, a new optional parameter to a function, some minor functionality... If it's a change in the infrastructure of PHP, then chances are that a mini release is not good enough for testing... Andi At 10:07 AM 8/9/2005 -0400, Ilia Alshanetsky wrote: Derick Rethans wrote: > I see it as: > 4.4 - no new features, no new additions. Just bugfixes. > 5.1 - no new major features, just smaller additions. > 6.0 - brand new experimental stuff. This breakdown looks good, although it'd be nice to quantify just what kind of "smaller additions" are acceptable for 5.1 branch. Ilia -- 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] Re: drastic memory consumption with a sequence of exceptions
Can you send a complete script which also passes $data that reproduces the
problem? Thanks.
At 05:27 PM 8/9/2005 +0200, Ron Korving wrote:
The problem occurs in this particular situation:
public function process($data)
{
$largeResultSet = $this->xmlParser->parseString($data);
foreach ($largeResultSet as &$item)
{
throw new Exception("error");
}
}
It only happens if the exception is thrown from within the foreach(). It
seems the $largeResultSet is not freed in this case. Using the foreach by
reference or not (&$item or $item) does not make a difference.
Ron
""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> It is very likely that this has something to do with DOM. It's a huge
piece
> of code though, making it hard to test where the problem really lies.
>
> ""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
> news:[EMAIL PROTECTED]
> > I've noticed that in a script of mine, memory consumption can explode
> quite
> > drastically when Exceptions are thrown, opposed to very normal memory
> > consumption when exceptions are not thrown.
> >
> > This is the idea:
> >
> > > class Obj
> > {
> > function process($i)
> > {
> > // do a lot of stuff, occupy a lot of memory within the scope of
this
> > function
> > throw new Exception("error");
> > }
> > }
> >
> > $obj = new Obj();
> > $errors = array();
> >
> > for ($i=0; $i < 60; $i++)
> > {
> > try
> > {
> > $obj->process();
> > }
> > catch (Exception $e)
> > {
> > $errors[] = $e->getMessage();
> > }
> > }
> > ?>
> >
> > When exceptions are not thrown, memory consumption is normal. The
method's
> > local vars are freed and not much more memory is used in the 50th pass
> > compared to the 1st. But when exceptions are thrown, memory consumption
> > increases quite a bit every pass. In the end (within the 60 passes of my
> > loop) over 8 MB's are used.
> >
> > Of course, I can unset a lot of data before throwing exceptions to free
up
> > memory and the problem will be solved. But it would be nicer if the
> cleanup
> > would happen as an exception is thrown.
> >
> > Can this be considered a bug or is this behavior known and accepted?
> >
> > Ron
--
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 5.5 or 6.0
On Tue, 09 Aug 2005 12:25:27 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > I think Unicode warrants a major version. I'd go with PHP 6 and > aim to release it before Perl 6 :) > From judging by a Perl 6 talk we attended at OSCON, that might > actually be a realistic goal. No rush please... Better after and better than before and half backed :-D --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to PHP5.1 and Apache 2.2 next year, need help
We've made a start a long time ago, and we do our best to keep all of PHP thread-safe. On paper it is. When a bug appears we fix it. Is it a risk to run it... I think it is but I have seen people running it successfully on IIS for a long time. (I still think that's a bad idea though). Andi At 07:09 PM 8/9/2005 +0200, Ron Korving wrote: Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and #2 can be accomplished, and that would at least be a good start. You are right about the libraries, but in time, even these may become thread safe (of course, likely not by anyone from the PHP-community). Why is this thread-safety such a taboo for many of the people here? Don't get me wrong, I know it can't be done in one go, but a start could be made, right? Perhaps that start could be made from PHP6 on? It doesn't have to be officially thread safe, because of all the libraries, but it could be thread-safer... Ron "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > steve roussey wrote: > > I have read and understand that there are a number of issues: > > > > 1. Problems with the Apache2 sapi > > 2. Problems with thread safety in the Zend Engine or PHP itself > > 3. Problems with thread-safety of modules > > You missed the most serious one. Thread safety problems in random > libraries you link in and we have absolutely no control over those. > > My stuff is far bigger and busier than yours, and I have absolutely no > intention to go threaded anytime soon. > > -Rasmus -- 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] Moving to PHP5.1 and Apache 2.2 next year, need help
steve roussey wrote: > I know my name can be easily traced to a website I own that only gets > about 10M pv/day but I also work as a consultant for another that gets > an order of magnitude more. So perhaps you do get more then them and > get 1B pv/day and your dad can beat up my dad. Ug. Strike that. I'm > just frustrated and stressed. (My own website doesn't even need the db > connection pooling just yet. Though it could use Keep-Alive..) Well, I can generally safely say that unless you also happen to work at Yahoo! in which case we are tied. ;) -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help
steve roussey wrote: > The setup we are striving for is to keep connections open all the way down the chain to the database. Ideally this would mean that we would use Apache 2.2 with the event MPM to hold user connections. Then the PHP threads would ideally hold persistent connections to the databases (either through using the Apache 2.1 mod_dbd or doing it in PHP itself). Have you considered using lighttpd with fastcgi loadbalancing and caching using mod_cml (cache meta language)? We have a similar problem here, and that's how we're going to solve it: By using lighttpd with fastcgi we seperate the webserver process from php processes (which could even work on other machines) which saves a lot of resources (memory/cpu/load) and enhance response-time for static files. For simple dynamic requests we can use mod_cml, which can "communicate" with PHP using memcached or the filesystem. Only if mod_cml cannot response to the request using cached data, php is needed. That speeds things up a lot, since cache-hits in mod_cml are not much slower than static files (because php is not touched in any way). It works perfectly with keep-alive. The connections from lighttpd process to fastcgi php processes are also persistent. It's no problem to use a php opcode cache. Perhaps db-connection pooling isn't an issue anymore, because the number of php-processes (= number of db connections) can be reduced drastically. Perhaps you can use apc_store()... or memcached to cache results of DB queries. http://trac.lighttpd.net/trac/wiki/CacheMetaLanguage http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP http://trac.lighttpd.net/trac/wiki/MigratingFromApache However, I don't think mod_php on a threaded webserver is a good idea, least of all for a setup under high load because of the arguments already mentioned in this thread and because most developers don't use threaded setups today. best regards, Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
At 02:07 PM 8/9/2005 -0400, George Schlossnagle wrote:
To duplicate the old semantic now you need to do:
if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
which is definitely uglier than
if(is_a($obj, 'MyFoo')) {}
George
But that's a good point. For the few frameworks that might require such
functionality they can use class_exists() or other methods. That doesn't
mean we should change instanceof for mainstream usage which is 99.99%.
In all languages, frameworks do some trickier stuff. In Java they often
mess with the ClassLoader, in C++ they deal with DSOs. This kind of
development paradigm is not mainstream and as long as there's a way to
achieve it, then that's what's important.
Even the people that mentioned it's s important. I bet that if I look
at their code, there's maybe 1 instance that actually would need this (if
at all).
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
On Aug 9, 2005, at 3:25 PM, Andi Gutmans wrote: I think Unicode warrants a major version. I'd go with PHP 6 and aim to release it before Perl 6 :) From judging by a Perl 6 talk we attended at OSCON, that might actually be a realistic goal. I think that's more than a 'might'. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 branched!
Per my online conversation with Andi, I will be committing the gcov stuff prior to the deep-freeze tomorrow morning -- expect a cvs commit and a follow-up e-mail on usage early tomorrow morning. John On Mon, 2005-08-08 at 23:11 -0700, Andi Gutmans wrote: > At 07:57 AM 8/9/2005 +0200, Sebastian Bergmann wrote: > >Andi Gutmans schrieb: > > > I just branched off PHP 5.1 (PHP_5_1). > > > > Does that mean that PHP_5_1 is in feature-freeze or are changes like > > the one Derick proposed (making type hint violations throw an exception > > instead of raising a fatal error) still possible for PHP 5.1? > > Feature-freeze. Deep freeze as discussed. The only thing the branch means > is that Dmitry and Andrei can start working on Unicode... > > Andi > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
At 09:41 PM 8/9/2005 +0200, Pierre-Alain Joye wrote: On Tue, 09 Aug 2005 12:25:27 -0700 [EMAIL PROTECTED] (Andi Gutmans) wrote: > I think Unicode warrants a major version. I'd go with PHP 6 and > aim to release it before Perl 6 :) > From judging by a Perl 6 talk we attended at OSCON, that might > actually be a realistic goal. No rush please... Better after and better than before and half backed :-D Well I'd like Unicode support out there as quickly as possible. That should be our main mission in my opinion (biggest bang for the buck). That said, obviously it shouldn't go out before it's ready, and there's still a lot of work and testing to be done... But anyway, it's too early to discuss :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, 09 Aug 2005 12:44:59 -0700 Andi Gutmans <[EMAIL PROTECTED]> wrote: > But that's a good point. For the few frameworks that might > require such functionality they can use class_exists() or other > methods. That doesn't mean we should change instanceof for > mainstream usage which is 99.99%. Where do you get this percentage? Do a fgrep -rn is_a\( in PEAR for example. And please no stupid comments (not you Andi the evil other ;)). There is plenty of good reasons to do this check. > In all languages, frameworks do some trickier stuff. In Java they > often mess with the ClassLoader, in C++ they deal with DSOs. These are _compiled_, _linked_ languages. The simple fact that you cannot compile your sources explain the tricks. PHP is (should I say was?) mostly a dynamic and scripting language. > This kind of development > paradigm is not mainstream and as long as there's a way to > achieve it, then that's what's important. What is important to me is that "you" deprecate things without acceptable alternatives. > Even the people that mentioned it's s important. I bet that > if I look at their code, there's maybe 1 instance that actually > would need this (if at all). Wrong --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
Hello George, Tuesday, August 9, 2005, 9:48:22 PM, you wrote: > On Aug 9, 2005, at 3:25 PM, Andi Gutmans wrote: >> I think Unicode warrants a major version. I'd go with PHP 6 and aim >> to release it before Perl 6 :) >> From judging by a Perl 6 talk we attended at OSCON, that might >> actually be a realistic goal. > I think that's more than a 'might' They nowadays even have folks that do not stick to their slow-steady-controlled dev masterplan. That in mind i guess they are only decreasing their dev speed - so folks hands on 6 - PHP 6 :-) > George Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
At 09:55 PM 8/9/2005 +0200, Pierre-Alain Joye wrote: On Tue, 09 Aug 2005 12:44:59 -0700 Andi Gutmans <[EMAIL PROTECTED]> wrote: > But that's a good point. For the few frameworks that might > require such functionality they can use class_exists() or other > methods. That doesn't mean we should change instanceof for > mainstream usage which is 99.99%. Where do you get this percentage? Do a fgrep -rn is_a\( in PEAR for example. And please no stupid comments (not you Andi the evil other ;)). There is plenty of good reasons to do this check. You are missing my point. I didn't say people don't use is_a(). There is a lot of PHP 4 compatible code which you'll find is_a() in. I said the amount of instances where you actually require the proposed behavior is neglgible. It happens with plug-in architectures which generally speaking, tend to also use Reflection functions (incl. class_exists, function_eixsts, etc.). > In all languages, frameworks do some trickier stuff. In Java they > often mess with the ClassLoader, in C++ they deal with DSOs. These are _compiled_, _linked_ languages. The simple fact that you cannot compile your sources explain the tricks. PHP is (should I say was?) mostly a dynamic and scripting language. Being a dynamically typed language doesn't mean everything should be dynamic. Does it mean we have to allow adding PPP properties/methods on the fly, allow for dynamic type hints ($ClassName $obj), and so on? I'm not expecting you to answer these questions but being dynamically typed doesn't mean the whole language is dynamic. That doesn't mean you can't/shouldn't argue your point, but I think this is a bad reason. > This kind of development > paradigm is not mainstream and as long as there's a way to > achieve it, then that's what's important. What is important to me is that "you" deprecate things without acceptable alternatives. Did I deprecate it? And yes, as I mentioned there is an acceptable alternative, although it seems it's not acceptable to you. I can't argue that point as it's how you feel. > Even the people that mentioned it's s important. I bet that > if I look at their code, there's maybe 1 instance that actually > would need this (if at all). Wrong We must be looking at completely different applications. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GCOV
Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. The changes are relatively minor and I've already run it past Andi. I'm trying to get around one last problem that maybe someone else can take care of: The basic issue is that our parsers have broken file/line preprocessor directives... since we're pre-generating these files and then committing them, things like #file and #line are breaking gcov because it's using them to look for source and the paths are from whomever committed them to begin with. I spoke with Andi about this at OSCON and we agreed that it's probably best when GCOV is enabled to strip those preprocessor directives out beforehand. Any other thoughts/comments? If no one has a better solution I'll commit the code later today. John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCOV
IIRC, we have a script that does this already for our release tarballs; should save some effort. --Wez. On 8/9/05, John Coggeshall <[EMAIL PROTECTED]> wrote: > Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. > The changes are relatively minor and I've already run it past Andi. I'm > trying to get around one last problem that maybe someone else can take > care of: > > The basic issue is that our parsers have broken file/line preprocessor > directives... since we're pre-generating these files and then committing > them, things like #file and #line are breaking gcov because it's using > them to look for source and the paths are from whomever committed them > to begin with. I spoke with Andi about this at OSCON and we agreed that > it's probably best when GCOV is enabled to strip those preprocessor > directives out beforehand. Any other thoughts/comments? If no one has a > better solution I'll commit the code later today. > > John > > -- > 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] GCOV
I also wrote one, i don't care which we use... it's a 5 line shell script :) On Tue, 2005-08-09 at 16:40 -0400, Wez Furlong wrote: > IIRC, we have a script that does this already for our release > tarballs; should save some effort. > > --Wez. > > On 8/9/05, John Coggeshall <[EMAIL PROTECTED]> wrote: > > Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. > > The changes are relatively minor and I've already run it past Andi. I'm > > trying to get around one last problem that maybe someone else can take > > care of: > > > > The basic issue is that our parsers have broken file/line preprocessor > > directives... since we're pre-generating these files and then committing > > them, things like #file and #line are breaking gcov because it's using > > them to look for source and the paths are from whomever committed them > > to begin with. I spoke with Andi about this at OSCON and we agreed that > > it's probably best when GCOV is enabled to strip those preprocessor > > directives out beforehand. Any other thoughts/comments? If no one has a > > better solution I'll commit the code later today. > > > > John > > > > -- > > 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] GCOV
Hi, I've already had a change to test your patch (I've even have asked my university for a server to put ithe reports on-line). I've also came into this issue, which happens because re2c is called in the wrong way (the output is printed to stdout, rather than directly to the file). Those files should be generated with 're2c -b -o output_file.c in_file.re'. (also: re2c should be called from the directory where the in_file.re is, so that it uses relatives paths) Conclusion, you just need to regenerate the parsers correctly. BTW, there was an error in your patch: it cleans the *.gcno files (which are generated at compile time) in cov_gen_clean() before running lcov, thus breaking the proccess. Nuno - Original Message - From: "John Coggeshall" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 09, 2005 9:38 PM Subject: [PHP-DEV] GCOV Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. The changes are relatively minor and I've already run it past Andi. I'm trying to get around one last problem that maybe someone else can take care of: The basic issue is that our parsers have broken file/line preprocessor directives... since we're pre-generating these files and then committing them, things like #file and #line are breaking gcov because it's using them to look for source and the paths are from whomever committed them to begin with. I spoke with Andi about this at OSCON and we agreed that it's probably best when GCOV is enabled to strip those preprocessor directives out beforehand. Any other thoughts/comments? If no one has a better solution I'll commit the code later today. John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCOV
Hello John, for the .re ones i could simply release re2c 0.9.10 and you use the new switch we especially made for that. If i knew we were going for 5.1 i had probably done that at OSCON but i didn't see any action required until just now. best regards marcus Tuesday, August 9, 2005, 10:44:01 PM, you wrote: > I also wrote one, i don't care which we use... it's a 5 line shell > script :) > On Tue, 2005-08-09 at 16:40 -0400, Wez Furlong wrote: >> IIRC, we have a script that does this already for our release >> tarballs; should save some effort. >> >> --Wez. >> >> On 8/9/05, John Coggeshall <[EMAIL PROTECTED]> wrote: >> > Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. >> > The changes are relatively minor and I've already run it past Andi. I'm >> > trying to get around one last problem that maybe someone else can take >> > care of: >> > >> > The basic issue is that our parsers have broken file/line preprocessor >> > directives... since we're pre-generating these files and then committing >> > them, things like #file and #line are breaking gcov because it's using >> > them to look for source and the paths are from whomever committed them >> > to begin with. I spoke with Andi about this at OSCON and we agreed that >> > it's probably best when GCOV is enabled to strip those preprocessor >> > directives out beforehand. Any other thoughts/comments? If no one has a >> > better solution I'll commit the code later today. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
Andi Gutmans wrote:
My the way, the performance argument wouldn't work because even if this
would be supported, we'd have to first "try" and load the class to make
sure we can actually check the instanceof, and only if the class doesn't
load then we would return false. So you won't save that step of trying
to load the interface/class.
I have wrestled with this 'problem' concerning instanceof since 5.0RC3
(actually Ard B. wrestled on the same code for a while - that is to say
Ard B is to my mind a talented ITer and his code is not be written of out
of hand - as mine might be if it was just my own, back to the point)
regardless of whether it is correct according to anyone else if I do:
if ($foo instanceof Bar) { /* yadayada */ }
and Bar is a non-existent class then why would one even bother to
try a load Bar - $foo is not going to be a Bar - otherwise Bar would
exist!
In the framework I built with Ard there are dataobjects that contain
fields objects - there are quite alot of fields classes and not every
'dataobject' contains everykind of field - in order to a have a generic field
handlers (for display/POST-processing etc) that can make use of instanceof
I have to load _every_ field class I possibly have - I find it a little
sad to hear that obviously the very concept of 'our' framework (let alone
the implementation).
I also know for a fact I don't fall into 1% of 'black magic'-edge-case-brilliant
but-evil-framework-php-programmers, I'm just not that good.
I realise I'm not a php developer and my 2cents are worth jack. hopefully this
plea from a just-above-average-joe-phper will enlighten you to the fact that
there are possibly more people than you realise who feel strongly that
instanceof's
current implementation should be changed (in accordance with Pierre's arguments)
kinds regards (and thanks for your time, and php ofcourse!),
Jochem
At 11:56 AM 8/9/2005 +0200, Pierre-Alain Joye wrote:
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
>
> > > This technique is already frequently used to cope with lazy
> > > loaded code, which even with cached code compilers, is pretty
> > > damn efficient in a scripted language (less IO operations,
> > > less parsing, less memory...)
> > >
> > > It is not about the fact we 'can' load the class, but that we
> > > dont 'want' to load the class.. - it's a waste of resources,
> > > memory, cpu etc. just for the sake of CS perfection..
> > >
> > > Last time I looked PHP was about getting thing done
> > > efficiently, not about giving your university professor a
> > > woody... ;)
> >
> > That's my point. The autoload magic (crap? :)) is not in cause
> > here. If you _test_ something, you do not expect the test
> > operator to abort your execution (fatal error).
>
> But you're testing for something that you *know* that can not
> exist in your code base. That is a broken test, so it should
> throw a fatal error.
function wrapperFoo($obj) {
if (is_a($obj, 'MyFoo') {
}
... other tests
}
worked before is_a was deprecated.
function wrapperFoo($obj) {
if ($obj instanceof MyFoo) {
}
}
Fatal error, if I _known_ that a class _cannot_ exist, I will not
test it then, but the thing is that I do _not_ know.
If I provide a library (ie, encoded), this library being used in an
unknown environment by unknown poeple, or if I have performance
requirement and I do not want to require/include a class if I do
not have to use it, then this test makes full sense. I fail to see
how hard is it to understand...
Derick, your post about type hinting talks about the exact same
problem, being able to work out fatal error or user mistakes.
--Pierre
--
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] GCOV
Hello Nuno, that's also absolutley correct for most .re'S. Tuesday, August 9, 2005, 10:49:02 PM, you wrote: > Hi, > I've already had a change to test your patch (I've even have asked my > university for a server to put ithe reports on-line). > I've also came into this issue, which happens because re2c is called in the > wrong way (the output is printed to stdout, rather than directly to the > file). Those files should be generated with 're2c -b -o output_file.c > in_file.re'. (also: re2c should be called from the directory where the > in_file.re is, so that it uses relatives paths) > Conclusion, you just need to regenerate the parsers correctly. > BTW, there was an error in your patch: it cleans the *.gcno files (which are > generated at compile time) in cov_gen_clean() before running lcov, thus > breaking the proccess. > Nuno > - Original Message - > From: "John Coggeshall" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, August 09, 2005 9:38 PM > Subject: [PHP-DEV] GCOV >> Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. >> The changes are relatively minor and I've already run it past Andi. I'm >> trying to get around one last problem that maybe someone else can take >> care of: >> >> The basic issue is that our parsers have broken file/line preprocessor >> directives... since we're pre-generating these files and then committing >> them, things like #file and #line are breaking gcov because it's using >> them to look for source and the paths are from whomever committed them >> to begin with. I spoke with Andi about this at OSCON and we agreed that >> it's probably best when GCOV is enabled to strip those preprocessor >> directives out beforehand. Any other thoughts/comments? If no one has a >> better solution I'll commit the code later today. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCOV
JFYI: -o doesn't work on all versions of re2c --Wez. On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote: > Hi, > > I've already had a change to test your patch (I've even have asked my > university for a server to put ithe reports on-line). > I've also came into this issue, which happens because re2c is called in the > wrong way (the output is printed to stdout, rather than directly to the > file). Those files should be generated with 're2c -b -o output_file.c > in_file.re'. (also: re2c should be called from the directory where the > in_file.re is, so that it uses relatives paths) > Conclusion, you just need to regenerate the parsers correctly. > > BTW, there was an error in your patch: it cleans the *.gcno files (which are > generated at compile time) in cov_gen_clean() before running lcov, thus > breaking the proccess. > > > Nuno > > > - Original Message - > From: "John Coggeshall" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, August 09, 2005 9:38 PM > Subject: [PHP-DEV] GCOV > > > > Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. > > The changes are relatively minor and I've already run it past Andi. I'm > > trying to get around one last problem that maybe someone else can take > > care of: > > > > The basic issue is that our parsers have broken file/line preprocessor > > directives... since we're pre-generating these files and then committing > > them, things like #file and #line are breaking gcov because it's using > > them to look for source and the paths are from whomever committed them > > to begin with. I spoke with Andi about this at OSCON and we agreed that > > it's probably best when GCOV is enabled to strip those preprocessor > > directives out beforehand. Any other thoughts/comments? If no one has a > > better solution I'll commit the code later today. > > > > John > > -- > 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] GCOV
Hello Wez, just to remind you: you are the only one using an old unsupport version that doesn't come with -o. marcus Tuesday, August 9, 2005, 10:55:43 PM, you wrote: > JFYI: -o doesn't work on all versions of re2c > --Wez. > On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I've already had a change to test your patch (I've even have asked my >> university for a server to put ithe reports on-line). >> I've also came into this issue, which happens because re2c is called in the >> wrong way (the output is printed to stdout, rather than directly to the >> file). Those files should be generated with 're2c -b -o output_file.c >> in_file.re'. (also: re2c should be called from the directory where the >> in_file.re is, so that it uses relatives paths) >> Conclusion, you just need to regenerate the parsers correctly. >> >> BTW, there was an error in your patch: it cleans the *.gcno files (which are >> generated at compile time) in cov_gen_clean() before running lcov, thus >> breaking the proccess. >> >> >> Nuno >> >> >> - Original Message - >> From: "John Coggeshall" <[EMAIL PROTECTED]> >> To: >> Sent: Tuesday, August 09, 2005 9:38 PM >> Subject: [PHP-DEV] GCOV >> >> >> > Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. >> > The changes are relatively minor and I've already run it past Andi. I'm >> > trying to get around one last problem that maybe someone else can take >> > care of: >> > >> > The basic issue is that our parsers have broken file/line preprocessor >> > directives... since we're pre-generating these files and then committing >> > them, things like #file and #line are breaking gcov because it's using >> > them to look for source and the paths are from whomever committed them >> > to begin with. I spoke with Andi about this at OSCON and we agreed that >> > it's probably best when GCOV is enabled to strip those preprocessor >> > directives out beforehand. Any other thoughts/comments? If no one has a >> > better solution I'll commit the code later today. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCOV
On Aug 9, 2005, at 4:55 PM, Wez Furlong wrote: JFYI: -o doesn't work on all versions of re2c Since when has PHP been concerned about not requiring the most-most recent version of a library, let alone a development tool? George --Wez. On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote: Hi, I've already had a change to test your patch (I've even have asked my university for a server to put ithe reports on-line). I've also came into this issue, which happens because re2c is called in the wrong way (the output is printed to stdout, rather than directly to the file). Those files should be generated with 're2c -b -o output_file.c in_file.re'. (also: re2c should be called from the directory where the in_file.re is, so that it uses relatives paths) Conclusion, you just need to regenerate the parsers correctly. BTW, there was an error in your patch: it cleans the *.gcno files (which are generated at compile time) in cov_gen_clean() before running lcov, thus breaking the proccess. Nuno - Original Message - From: "John Coggeshall" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 09, 2005 9:38 PM Subject: [PHP-DEV] GCOV Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. The changes are relatively minor and I've already run it past Andi. I'm trying to get around one last problem that maybe someone else can take care of: The basic issue is that our parsers have broken file/line preprocessor directives... since we're pre-generating these files and then committing them, things like #file and #line are breaking gcov because it's using them to look for source and the paths are from whomever committed them to begin with. I spoke with Andi about this at OSCON and we agreed that it's probably best when GCOV is enabled to strip those preprocessor directives out beforehand. Any other thoughts/comments? If no one has a better solution I'll commit the code later today. John -- 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 George Schlossnagle -- Vice President of Engineering -- OmniTI Computer Consulting -- http://www.omniti.com
Re: [PHP-DEV] GCOV
No, I'm not (both not the only one using an older version, nor am I necessarily using an older version). Until someone points out a re2c bug that actually impacts PHP, I'm in no rush to run around upgrading more than 20 machines. --Wez. On 8/9/05, Marcus Boerger <[EMAIL PROTECTED]> wrote: > Hello Wez, > > just to remind you: you are the only one using an old unsupport version > that doesn't come with -o. > > marcus > > Tuesday, August 9, 2005, 10:55:43 PM, you wrote: > > > JFYI: -o doesn't work on all versions of re2c > > > --Wez. > > > On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I've already had a change to test your patch (I've even have asked my > >> university for a server to put ithe reports on-line). > >> I've also came into this issue, which happens because re2c is called in the > >> wrong way (the output is printed to stdout, rather than directly to the > >> file). Those files should be generated with 're2c -b -o output_file.c > >> in_file.re'. (also: re2c should be called from the directory where the > >> in_file.re is, so that it uses relatives paths) > >> Conclusion, you just need to regenerate the parsers correctly. > >> > >> BTW, there was an error in your patch: it cleans the *.gcno files (which > >> are > >> generated at compile time) in cov_gen_clean() before running lcov, thus > >> breaking the proccess. > >> > >> > >> Nuno > >> > >> > >> - Original Message - > >> From: "John Coggeshall" <[EMAIL PROTECTED]> > >> To: > >> Sent: Tuesday, August 09, 2005 9:38 PM > >> Subject: [PHP-DEV] GCOV > >> > >> > >> > Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. > >> > The changes are relatively minor and I've already run it past Andi. I'm > >> > trying to get around one last problem that maybe someone else can take > >> > care of: > >> > > >> > The basic issue is that our parsers have broken file/line preprocessor > >> > directives... since we're pre-generating these files and then committing > >> > them, things like #file and #line are breaking gcov because it's using > >> > them to look for source and the paths are from whomever committed them > >> > to begin with. I spoke with Andi about this at OSCON and we agreed that > >> > it's probably best when GCOV is enabled to strip those preprocessor > >> > directives out beforehand. Any other thoughts/comments? If no one has a > >> > better solution I'll commit the code later today. > > > Best regards, > Marcus > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCOV
Hello Wez, i fixed some bugs in re2c since -o was added. Some of those were serious ones. Whether they affect pdo i cannot tell but for one issue i know that it may affect ext/standard usage (depending on the compiler iirc). Maybe jani can recall the reasons why and when we increased the re2c version requirement. marcus Tuesday, August 9, 2005, 11:01:56 PM, you wrote: > No, I'm not (both not the only one using an older version, nor am I > necessarily using an older version). > Until someone points out a re2c bug that actually impacts PHP, I'm in > no rush to run around upgrading more than 20 machines. > --Wez. > On 8/9/05, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Hello Wez, >> >> just to remind you: you are the only one using an old unsupport version >> that doesn't come with -o. >> >> marcus >> >> Tuesday, August 9, 2005, 10:55:43 PM, you wrote: >> >> > JFYI: -o doesn't work on all versions of re2c >> >> > --Wez. >> >> > On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> >> >> I've already had a change to test your patch (I've even have asked my >> >> university for a server to put ithe reports on-line). >> >> I've also came into this issue, which happens because re2c is called in >> >> the >> >> wrong way (the output is printed to stdout, rather than directly to the >> >> file). Those files should be generated with 're2c -b -o output_file.c >> >> in_file.re'. (also: re2c should be called from the directory where the >> >> in_file.re is, so that it uses relatives paths) >> >> Conclusion, you just need to regenerate the parsers correctly. >> >> >> >> BTW, there was an error in your patch: it cleans the *.gcno files (which >> >> are >> >> generated at compile time) in cov_gen_clean() before running lcov, thus >> >> breaking the proccess. >> >> >> >> >> >> Nuno >> >> >> >> >> >> - Original Message - >> >> From: "John Coggeshall" <[EMAIL PROTECTED]> >> >> To: >> >> Sent: Tuesday, August 09, 2005 9:38 PM >> >> Subject: [PHP-DEV] GCOV >> >> >> >> >> >> > Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed. >> >> > The changes are relatively minor and I've already run it past Andi. I'm >> >> > trying to get around one last problem that maybe someone else can take >> >> > care of: >> >> > >> >> > The basic issue is that our parsers have broken file/line preprocessor >> >> > directives... since we're pre-generating these files and then committing >> >> > them, things like #file and #line are breaking gcov because it's using >> >> > them to look for source and the paths are from whomever committed them >> >> > to begin with. I spoke with Andi about this at OSCON and we agreed that >> >> > it's probably best when GCOV is enabled to strip those preprocessor >> >> > directives out beforehand. Any other thoughts/comments? If no one has a >> >> > better solution I'll commit the code later today. >> >> >> Best regards, >> Marcus >> >> Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: FrOSCon - "FOSDEM" in Germany
Weiredly had the wrong adress in my contacts. So, here's what was intended to get here... Original Message Hi all! Sebastian has blogged [1] about FrOSCon, a pondon to FOSDEM in Germany, St. Augustin. If there is interesst, I'd love to see a PHP/PECL/PEAR room there. Sebastian is member of the organisation team, so I assume that should not be a problem. Interesst? Comments? Regards, Toby [1] http://www.sebastian-bergmann.de/blog/archives/520-FrOSCon.html P.S. Sorry for the x-post and please redirect flames on that directly to /dev/null. -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help
On 8/9/05, Andreas Korthaus <[EMAIL PROTECTED]> wrote: > By using lighttpd with fastcgi we seperate the webserver process from > php processes (which could even work on other machines)... Someone else emailed me about using FastCGI with Apache 2.1/event but I just figured that there would be a significant slowdown using FastCGI rather than a module/handler. (Currently I compile PHP into Apache statically and turn off Apache's dynamic module loading ability -- something I couldn't figure out in Apache2). What is your experience with FastCGI? > For simple dynamic requests we can use mod_cml Sadly, this won't work with any system I manage since we do a lot of stat reporting, even on a per user basis. And we need to have PHP loaded to know the user, etc... Still, I looked at lighttpd and it looks promising. The one thing that started all of this was Apache 2.1's event MPM that used a single thread to handle all open Keep-Alives looked very efficient. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCOV
On Tue, 2005-08-09 at 21:49 +0100, Nuno Lopes wrote: > BTW, there was an error in your patch: it cleans the *.gcno files (which are > generated at compile time) in cov_gen_clean() before running lcov, thus > breaking the proccess. Opps. I'll fix that when I commit. As soon as we get the parsers fixed up I'll make some final tweaks and get it in CVS John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help
steve roussey wrote: > On 8/9/05, Andreas Korthaus <[EMAIL PROTECTED]> wrote: > >>By using lighttpd with fastcgi we seperate the webserver process from >>php processes (which could even work on other machines)... > > > Someone else emailed me about using FastCGI with Apache 2.1/event but > I just figured that there would be a significant slowdown using > FastCGI rather than a module/handler. (Currently I compile PHP into > Apache statically and turn off Apache's dynamic module loading ability > -- something I couldn't figure out in Apache2). What is your > experience with FastCGI? PHP by default compiles as a non-pic shared library now which is just as fast as a static build inside Apache since it is the pic stuff that slows down a DSO. So there is really no need for static builds anymore, unless you happen to be on a fringe OS that doesn't support non-pic shared libs. > Still, I looked at lighttpd and it looks promising. The one thing that > started all of this was Apache 2.1's event MPM that used a single > thread to handle all open Keep-Alives looked very efficient. I think you are probably better off solving this in a lightweight frontend process. Chances are you are going to need lingerd if you go keepalive, so perhaps the real solution is to make lingerd handle not just the shutdown, but also the startup of the request. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help
Hi Steve, From my experiences, FastCGI performance is comparable to mod_php. Andi At 02:24 PM 8/9/2005 -0700, steve roussey wrote: On 8/9/05, Andreas Korthaus <[EMAIL PROTECTED]> wrote: > By using lighttpd with fastcgi we seperate the webserver process from > php processes (which could even work on other machines)... Someone else emailed me about using FastCGI with Apache 2.1/event but I just figured that there would be a significant slowdown using FastCGI rather than a module/handler. (Currently I compile PHP into Apache statically and turn off Apache's dynamic module loading ability -- something I couldn't figure out in Apache2). What is your experience with FastCGI? > For simple dynamic requests we can use mod_cml Sadly, this won't work with any system I manage since we do a lot of stat reporting, even on a per user basis. And we need to have PHP loaded to know the user, etc... Still, I looked at lighttpd and it looks promising. The one thing that started all of this was Apache 2.1's event MPM that used a single thread to handle all open Keep-Alives looked very efficient. -- 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] Re: Moving to PHP5.1 and Apache 2.2 next year, need help
That is great to know. In that case, I won't worry about threading again. I'm assuming that the 4.3.0 Release Announcement that FastCGI was removed is bogus or reversed. Unfortunately my source for mysql connection pooling was never upgraded to support 4.1's APIs. If anyone knows one, pass it by me. :) Thanks! On 8/9/05, Andi Gutmans <[EMAIL PROTECTED]> wrote: > Hi Steve, > > From my experiences, FastCGI performance is comparable to mod_php. > > Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: internal class' static properties
Marcus Boerger schrieb:
regarding static props the solution is to define another hash table
in the class_entry that holdes the initial values for the static
variables. During minit these would be copied to the used hash table,
done. But even though the solution is pretty easy i do not know if we
really want to support that. We have default properties and all that
stuff already.
I attached a patch, which fixes the static property issue for me,
though I didn't test as a webserver module yet.
> Can't we simply check if default values for static
> properties wouldn't do the job and if there is something missing in
> that?
Huh? I even think that zend_std_get_static_property() is not enough...
This forces you to have real zvals for your static properties.
Maybe a minor issue (but still an issue :)
> class consts should be easy and we two times had a patch for that.
> And i definitively ask to support that since otherwise we flood our
> namespace, see pdo, spl and the amount of defines there. With a peep
> to pecl i see tons of more consts (especially in http).
The patch also contains API for class constants, tough valgrind reports
some odd errors about the constants_table (among "some" others...)
Anyway, I'd be glad if the patch could be reviewed, fixed (as it's most
probably not totally accurate) and -even partially- applied.
Thanks,
Michael
Index: Zend/zend.h
===
RCS file: /repository/ZendEngine2/zend.h,v
retrieving revision 1.293
diff -u -r1.293 zend.h
--- Zend/zend.h 3 Aug 2005 13:30:46 - 1.293
+++ Zend/zend.h 9 Aug 2005 21:56:06 -
@@ -331,7 +331,8 @@
HashTable function_table;
HashTable default_properties;
HashTable properties_info;
- HashTable *static_members;
+ HashTable default_static_properties;
+ HashTable static_properties;
HashTable constants_table;
struct _zend_function_entry *builtin_functions;
Index: Zend/zend_API.c
===
RCS file: /repository/ZendEngine2/zend_API.c,v
retrieving revision 1.296
diff -u -r1.296 zend_API.c
--- Zend/zend_API.c 8 Aug 2005 14:25:05 - 1.296
+++ Zend/zend_API.c 9 Aug 2005 21:56:11 -
@@ -759,7 +759,7 @@
*scope = class_type;
zend_hash_apply_with_argument(&class_type->default_properties,
(apply_func_arg_t) zval_update_constant, (void *) 1 TSRMLS_CC);
- zend_hash_apply_with_argument(class_type->static_members,
(apply_func_arg_t) zval_update_constant, (void *) 1 TSRMLS_CC);
+
zend_hash_apply_with_argument(&class_type->default_static_properties,
(apply_func_arg_t) zval_update_constant, (void *) 1 TSRMLS_CC);
*scope = old_scope;
class_type->constants_updated = 1;
}
@@ -2126,7 +2126,7 @@
access_type |= ZEND_ACC_PUBLIC;
}
if (access_type & ZEND_ACC_STATIC) {
- target_symbol_table = ce->static_members;
+ target_symbol_table = &ce->default_static_properties;
} else {
target_symbol_table = &ce->default_properties;
}
@@ -2382,6 +2382,155 @@
return value;
}
+
+static inline zval *new_zval(zend_bool persistent)
+{
+ zval *z = pemalloc(sizeof(zval), persistent);
+ INIT_PZVAL(z);
+ return z;
+}
+
+static inline zval *tmp_zval(void)
+{
+ zval *z;
+ ALLOC_ZVAL(z);
+ z->is_ref = 0;
+ z->refcount = 0;
+ return z;
+}
+
+ZEND_API int zend_declare_class_constant(zend_class_entry *ce, char *name,
size_t name_length, zval *value TSRMLS_DC)
+{
+ return zend_hash_update(&ce->constants_table, name, name_length,
&value, sizeof(zval *), NULL);
+}
+
+ZEND_API int zend_declare_class_constant_long(zend_class_entry *ce, char
*name, size_t name_length, long value TSRMLS_DC)
+{
+ zval *constant = new_zval(ce->type & ZEND_INTERNAL_CLASS);
+ ZVAL_LONG(constant, value);
+ return zend_declare_class_constant(ce, name, name_length, constant
TSRMLS_CC);
+}
+
+ZEND_API int zend_declare_class_constant_bool(zend_class_entry *ce, char
*name, size_t name_length, zend_bool value TSRMLS_DC)
+{
+ zval *constant = new_zval(ce->type & ZEND_INTERNAL_CLASS);
+ ZVAL_BOOL(constant, value);
+ return zend_declare_class_constant(ce, name, name_length, constant
TSRMLS_CC);
+}
+
+ZEND_API int zend_declare_class_constant_double(zend_class_entry *ce, char
*name, size_t name_length, double value TSRMLS_DC)
+{
+ zval *constant = new_zval(ce->type & ZEND_INTERNAL_CLASS);
+ ZVAL_DOUBLE(constant, value);
+ return zend_declare_class_constant(ce, name, name_length, constant
TSRMLS_CC);
+}
+
+ZEND_API int zend_declare_class_constant_string(zend_class_entry *ce, char
*name, size_t name_length, char *value TSRMLS_DC)
+{
+ return zend_declare_class_constant_stringl(ce, name, name_length,
val
Re: [PHP-DEV] Re: RC1, instanceof?
On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
>
> if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
Unfortunately, class_exists() still calls __autoload(). Un-deprecating
is_a() seems to be an easy way to resolve this situation.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
Hello Daniel,
RTFM: try class_exists(..., false)
marcus
Wednesday, August 10, 2005, 12:38:49 AM, you wrote:
> On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
>>
>> if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
> Unfortunately, class_exists() still calls __autoload(). Un-deprecating
> is_a() seems to be an easy way to resolve this situation.
> --Dan
> --
> T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
> data intensive web and database programming
> http://www.AnalysisAndSolutions.com/
> 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RC1, instanceof?
On Wed, Aug 10, 2005 at 01:03:06AM +0200, Marcus Boerger wrote:
> Wednesday, August 10, 2005, 12:38:49 AM, you wrote:
> > On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
> >>
> >> if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
> >
> > Unfortunately, class_exists() still calls __autoload(). Un-deprecating
> > is_a() seems to be an easy way to resolve this situation.
>
> RTFM: try class_exists(..., false)
Good point. Forgot about that. Similarly, George's example forgot about
that parameter also.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help
On 8/9/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > PHP by default compiles as a non-pic shared library now which is just as > fast as a static build inside Apache since it is the pic stuff that > slows down a DSO. So there is really no need for static builds anymore, > unless you happen to be on a fringe OS that doesn't support non-pic > shared libs. This is good to know. I guess it is time to rewrite my build-a-new-webserver script. It has seen changes over the years but not a comprehensive reevaluation. > > Still, I looked at lighttpd and it looks promising. The one thing that > > started all of this was Apache 2.1's event MPM that used a single > > thread to handle all open Keep-Alives looked very efficient. > > I think you are probably better off solving this in a lightweight > frontend process. Chances are you are going to need lingerd if you go > keepalive, so perhaps the real solution is to make lingerd handle not > just the shutdown, but also the startup of the request. You know, I remember considering lingerd a long time ago... and I feel like an idiot for not using all these years! If it is not in my script it doesn't cross my mind. So I have that on today's todo list. (This seems like something Apache2 should do automatically in its threaded MPMs, not that we would be using mod_php here or anything, but maybe I am confused by your statement above, so I have tried not to email back until I could find more information, but I could not. In the lingerd website it says "lingerd can only do an effective job if HTTP Keep-Alives are turned off" which is confusing when compared to your statement above. Unless you are combining it with the lightweight process (I assume a proxy server). Then it makes sense. Except for the part about having lingerd hande the startup of the request, at which point I'm clueless again. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help
steve roussey wrote: Someone else emailed me about using FastCGI with Apache 2.1/event but I just figured that there would be a significant slowdown using FastCGI rather than a module/handler. (Currently I compile PHP into Apache statically and turn off Apache's dynamic module loading ability -- something I couldn't figure out in Apache2). What is your experience with FastCGI? There are some different benchmarks with lighttpd+php: http://trac.lighttpd.net/trac/wiki/ But I only trust my own benchmarks, and here I couldn't measure a really big difference, lighttpd + fastcgi seems to be slightly faster than Apache 1.3 + mod_php with my setup. But I think it depends on your application and setup. A big difference I noticed was used cpu, memory and load - lighttpd was by far more efficient here. If you're benchmarking lighttpd you should have a look at the following chapter from documentation: http://lighttpd.net/documentation/performance.html Still, I looked at lighttpd and it looks promising. The one thing that started all of this was Apache 2.1's event MPM that used a single thread to handle all open Keep-Alives looked very efficient. lighttpd does the same, it's a non-blocking webserver with only one process. The one process cares about keep-alives... and delegates handling of PHP-Requests to a number of loadbalanced, persistent PHP Processes using FastCGI. Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
