[PHP-DEV] Writing PHPT tests
Hi - for any of you that are writing PHPT tests for existing extensions
- I put a PHP script called generate_phpt.php into PHP 5.3 yesterday
which might help a little.
It's quite a simple command line script (Raghu and I wrote it last
year), it works by looking at the {{{proto line for a function in PHP
source code and construct a test case frame from it. It can be used to
construct very simple tests cases - or to turn an existing PHP file into
PHPT format. It doesn't try and guess what the results of a test should
be :-). I will document it properly on qa.php.net later. In the meantime:
php generate_phpt.php --help
tells you what it's supposed to do.
Zoe
PS - It doesn't work for PHP6 right now because the {{{proto line is
different.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build failure on windows PHP_5_2
On 02/02/2008, Gregory Beaver <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm getting unresolved external symbol xmlXPathCompiledEvalToBoolean > with the latest zip.zip, any plans to update libxml2 to .31 soon in zip.zip? > > Greg > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > The win32 snapshot builds have been done since Jan 20/21, so maybe there is more than 1 library to fix -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] An Idea for PDO 2
If there is no CLA, will that mean we will not get the PDO 2 drivers we need to be able to communicate with the databases? Could, for example, MySQL say without a CLA we are not contributing code? If so, what is the alternatives? Wait until we have some hacked up version from someone not on the inside track? Its a shame that their is not a legal understanding of the spirit of the law, rather than just the letter of the law. If their is no CLA, what are the alternatives? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build failure on windows PHP_5_2
The win32 snapshot builds have been done since Jan 20/21, so maybe there is more than 1 library to fix No, the errors that caused the original failure were fixed within a day or two. Also the snaps libxml is up to date, it's just the zip.zip one that isn't. Machine probably needs a kick. Rob's download page is at http://ctindustries.net/libxml/ if anyone needs to update their libxml copy locally. - Steph -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- 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] json_encode() bug
On Fri, 25 Jan 2008, Stanislav Malyshev wrote:
> Hi!
>
> Right now, if json_encode sees wrong UTF-8 data, it just cuts the string in
> the middle, no error returned, no message produced. Example:
>
> var_dump(json_encode("ab\xE0"));
> var_dump(json_encode("ab\xE0\""));
>
> Both strings get cut at "ab". I think it's not a good idea to just silently
> cut the data. In fact, I think it is a bug caused by this code in
> ext/json/utf8_to_utf16.c:
> if (c < 0) {
> return UTF8_END ? the_index : UTF8_ERROR;
> }
> which inherited this bug from code published on json.org. It should be:
> if (c < 0) {
> return (c == UTF8_END) ? the_index : UTF8_ERROR;
> }
> Now this is an easy fix but would lead to bad strings silently converted to
> empty strings. The question is - should we have an error there? If so, which
> one - E_WARNING, E_NOTICE? I'm for E_WARNING.
> Also filed as bug #43941.
> Any comments?
Like I mentioned before (I think), it should not return an empty string
of course because programmatically it's not possible to check for this.
As most of our functions return false in those cases, so should this
function.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] An Idea for PDO 2
Hi, On Feb 2, 2008 12:15 PM, Richard Quadling <[EMAIL PROTECTED]> wrote: > If there is no CLA, will that mean we will not get the PDO 2 drivers > we need to be able to communicate with the databases? It would be really nice if the pro CLA camp stops to condition the existence of PDO (or its future) to the CLA acceptation. That's simply wrong. Oracle, IBM and MySql (which states their point already, they will accept the choice made by the php project) contribute already to php. The question is actually: Can they continue to ignore PHP or do they have to have their respective products working smoothly with PHP? The answer is pretty obvious and we see announces on a regular basis to proove they have to support PHP. Read the respective interviews or stories about PHP, the tone is completely different now than a year ago. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Writing PHPT tests
Hi Zoe,
I notice also that the testcase generator and the testcases we have been
committing differ slightly from the conventions listed at:
http://qa.php.net/write-test.php . This was based on feedback we received
so I think that http://qa.php.net/write-test.php should be updated.
Specifically the convention of writing multiple small tests to cover
basic, variation and error cases separately differs from the naming
convention suggested on the QA pages. We have also been following a
convention w.r.t comments in the testcase which I think is helpful so I'd
suggest we cover this too. Since the testcase generator adds these
comments its worth documenting them.
I'll produce a patch to the documentation for review if you like.
Rob Nicholson
From:
zoe <[EMAIL PROTECTED]>
To:
internals@lists.php.net
Date:
02/02/2008 11:21
Subject:
[PHP-DEV] Writing PHPT tests
Hi - for any of you that are writing PHPT tests for existing extensions
- I put a PHP script called generate_phpt.php into PHP 5.3 yesterday
which might help a little.
It's quite a simple command line script (Raghu and I wrote it last
year), it works by looking at the {{{proto line for a function in PHP
source code and construct a test case frame from it. It can be used to
construct very simple tests cases - or to turn an existing PHP file into
PHPT format. It doesn't try and guess what the results of a test should
be :-). I will document it properly on qa.php.net later. In the meantime:
php generate_phpt.php --help
tells you what it's supposed to do.
Zoe
PS - It doesn't work for PHP6 right now because the {{{proto line is
different.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Hello Wez, keeping the discussion on this list is a major mistake. And it is actually the reason why everyone outside this list is against it. And whether you read blogs or not does not interest anybody at all - unless you are going to comment on every single blog that mentions PHP and CLA. So far PHP is open source! Respect this please!! Open means open!!! I am crossposting to internals again. People should know what is going on. Otherwise we could simply sign NDAs and be done. marcus Saturday, February 2, 2008, 6:36:17 AM, you wrote: > On Feb 1, 2008, at 10:24 PM, Steph Fox wrote: >> Wez, >> >> The only difference between my initial proposal, the one Ben Ramsey >> posted and this one from Marcus is that they're getting more >> complex, *without anyone actually discussing anything at all*. > On the contrary, there's been plenty of discussion going on. Despite > my request that we keep the discussion on this list, people have been > talking to each other in real life, on the phone, talking on IRC, IM, > posting thoughts and comments to blogs and so forth. Some comments > positive, some negative, but discussion nonetheless. > I've been making an effort to read the various blog entries, even > those in foreign languages (thanks to a combination of blog searching > tools and google translation tools) and keep an eye on IRC when I have > a spare minute or two. >> ... He had a response from Jay, who said this had already been >> discussed. According to him, >> >> "There was some dissent among members about the core and the spec/ >> API docs being non-CLA'd which is why the proposal is currently the >> way it is. I know that various legal teams had concerns about PDO >> core not being under CLA, but if a case is made in the community for >> this, perhaps minds may change." >> >> Now you're saying there's no problem with this approach? Where's the >> real discussion going on? > No, I didn't say that there's no problem, I said that this sounds > reasonable. > For example, a problem with this general solution is still that > database experts from multiple sources would not be able to directly > co-operate on the PDO core. However, it sounds to me like a > reasonable (though sub-optimal, from a technical and productivity > point of view) compromise to be able to accept feedback and > suggestions and have those gated through the PDO core maintainers. > That's just my opinion; I certainly don't speak for anyone else. >> It's not a bad thing per se to separate PECL and PHP, but it does >> beg the question of how to approach distributions/snaps, which is >> AFAICS the only reason anything not essential to PHP itself is in >> the core in the first place. Nobody's sat down and worked it through >> properly, despite Lukas' repeated requests. > One reason that no one has discussed that is because it is not > directly related to the question of PDO and how to best get the > vendors involved. Once we've figured that out, we can iron out the > details of the implementation. >> I think if we did this it would have to be as part of a broader >> approach, with a full re-evaluation of the PHP/PECL relationship, >> some hard thinking about distribution mechanisms for PECL, and some >> serious decisions about setup recommendations. It's really not the >> quick fix it appears to be... and making it so without putting that >> effort into it would hit the PHP userbase harder than anyone else. > And that's well beyond the scope of PDO. Remember, one of the > concerns raised by the community was that this business would > interfere with the rest of PHP; the suggestions we've made so far have > been intentionally very focused to avoid getting into that. > Again; first let's see if we can find an acceptable way to take their > contributions before moving on to those finer points. >> BTW I'm still waiting to hear about the other alternatives that were >> discussed behind our backs, and the objections against them... and I >> say 'behind our backs' simply because nobody seems to want to tell us! > We talked about whether the various vendors could work on various > combinations of pieces of the code if they were or were not CLA'd. > I'm sure you don't really need me to list the various combinations of > CLA, not CLA, in PHP, in PECL, outside of PHP, and hosted individually > by the vendors. It was not a very exciting discussion. > The main realization was that the vendors could not co-operate with > each other on code without a CLA in place, and that some of them would > not be able to co-operate with the community without a CLA in place. > --Wez. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] zend_call_method_with_N_params()
Hello Masaki, I did not say in any word that you cannot get those 3 and 4 param versions. All I am saying is that the use of C99 va-macros is not possible. Simply come up with a va-macro (and emalloc) free implementation and we can add it. marcus Friday, February 1, 2008, 7:00:09 AM, you wrote: > it seems really unfortunate...:) but I understand your reasons, and then > I'm looking forward to fixes in 5.3 or 6. thank you! > Marcus Boerger wrotes: >> Hello Masaki, >> >> unfortunately we cannot use any C99 extension and must stick to C89. >> Also I do not really see a reason to use ... in the actual function >> definition. The reason for the way the function is written, is to avoid >> using emalloc. Now, we can probably live with up to four parameters for >> PHP 5.3 and HEAD. But we cannot allow this in 5.2 as it would be an API >> change. So if you can comeup with a change that will simply add two >> parameters for zend_call_method() and provide the two additionla macros >> as well as fixing the ones being present already then *I* think it is >> fine. >> >> marcus >> >> Thursday, January 31, 2008, 3:58:51 PM, you wrote: >> >>> hello marcus, >> >>> after a long interval, I've restarted to hack PHP and ZE again, and I >>> found that zend_call_method could take only 2 args at most...(I just >>> wanted to call methods w/ 3 or more args in my extensions:) >> >>> I think we can easily rewrite this w/ va_list, and since most of the >>> extensions are call zend_call_method() via zend_call_method_with* macro >>> so that no BC breaking things will happen. >> >>> # AFAIK only spl use zend_call_method() directly and perhaps we can >>> easily sync w/ updated interfaces (TSRM fixes will do) >> >>> pathces are here: >>> [PHP_5_2 / PHP_5_3] >>> http://labs.gree.jp/data/patch/zend_interfaces_var_list.php_5_2.patch >> >>> [HEAD] >>> http://labs.gree.jp/data/patch/zend_interfaces_var_list.head.patch >> >>> # C99 feature (__VA_ARGS__) is used in my patch for HEAD...(is it >>> acceptable?) >> >>> if this is ok, it's much appreciated if you apply these patches. thank you. >> >>> -- >>> Masaki Fujimoto >>> <[EMAIL PROTECTED]> >> >> >> >> >> Best regards, >> Marcus >> > -- > Masaki Fujimoto > <[EMAIL PROTECTED]> Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Hi, I think the biggest myths in this CLA discussion are: > > The main realization was that the vendors could not co-operate with > > each other on code without a CLA in place, and that some of them would > > not be able to co-operate with the community without a CLA in place. and: > > For example, a problem with this general solution is still that > > database experts from multiple sources would not be able to directly > > co-operate on the PDO core. However, it sounds to me like a > > reasonable (though sub-optimal, from a technical and productivity > > point of view) compromise to be able to accept feedback and > > suggestions and have those gated through the PDO core maintainers. >> > > --Wez. The history of open sources and free softwares (generally speaking, not specifically FSF) tells us that they can work without restrictions, of any form. If one has doubts, he can look at the X.org projects or any other areas where NDA and CLA are (I can soon say "were") a must have. Almost all vendors are now opening theirs specs and collaborate with the respective open source projects. Their teams even provide patches and improvements on a regular basis. How does it happen? The project leaders knew that vendors will have no choice in the end. The problem with php is that we are easily influenced by a couple of big companies. A couple of invitation here, some special events there and suddenly the old evil is becoming our best friends. But they were not the evil, they are also not out best friends. They simply do their jobs, keep their market share using all well known marketing actions (that's not badly meant). -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: build failure on windows PHP_5_2
Gregory Beaver wrote: > Hi all, > > I'm getting unresolved external symbol xmlXPathCompiledEvalToBoolean > with the latest zip.zip, any plans to update libxml2 to .31 soon in zip.zip? > > Greg For now, until it gets updated Greg, just grab the xml libraries from here http://ctindustries.net/libxml/ and dump the libs and include files over the ones you get in zip.zip - then php builds perfectly again Elizabeth Smith -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Be fair, this is an open list. Anyone can join it, and it keeps the noise levels down on [EMAIL PROTECTED] Please? ;) http://news.php.net/php.pdo - Steph - Original Message - From: "Marcus Boerger" <[EMAIL PROTECTED]> To: "Wez Furlong" <[EMAIL PROTECTED]> Cc: "Steph Fox" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Sent: Saturday, February 02, 2008 12:50 PM Subject: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2 Hello Wez, keeping the discussion on this list is a major mistake. And it is actually the reason why everyone outside this list is against it. And whether you read blogs or not does not interest anybody at all - unless you are going to comment on every single blog that mentions PHP and CLA. So far PHP is open source! Respect this please!! Open means open!!! I am crossposting to internals again. People should know what is going on. Otherwise we could simply sign NDAs and be done. marcus Saturday, February 2, 2008, 6:36:17 AM, you wrote: On Feb 1, 2008, at 10:24 PM, Steph Fox wrote: Wez, The only difference between my initial proposal, the one Ben Ramsey posted and this one from Marcus is that they're getting more complex, *without anyone actually discussing anything at all*. On the contrary, there's been plenty of discussion going on. Despite my request that we keep the discussion on this list, people have been talking to each other in real life, on the phone, talking on IRC, IM, posting thoughts and comments to blogs and so forth. Some comments positive, some negative, but discussion nonetheless. I've been making an effort to read the various blog entries, even those in foreign languages (thanks to a combination of blog searching tools and google translation tools) and keep an eye on IRC when I have a spare minute or two. ... He had a response from Jay, who said this had already been discussed. According to him, "There was some dissent among members about the core and the spec/ API docs being non-CLA'd which is why the proposal is currently the way it is. I know that various legal teams had concerns about PDO core not being under CLA, but if a case is made in the community for this, perhaps minds may change." Now you're saying there's no problem with this approach? Where's the real discussion going on? No, I didn't say that there's no problem, I said that this sounds reasonable. For example, a problem with this general solution is still that database experts from multiple sources would not be able to directly co-operate on the PDO core. However, it sounds to me like a reasonable (though sub-optimal, from a technical and productivity point of view) compromise to be able to accept feedback and suggestions and have those gated through the PDO core maintainers. That's just my opinion; I certainly don't speak for anyone else. It's not a bad thing per se to separate PECL and PHP, but it does beg the question of how to approach distributions/snaps, which is AFAICS the only reason anything not essential to PHP itself is in the core in the first place. Nobody's sat down and worked it through properly, despite Lukas' repeated requests. One reason that no one has discussed that is because it is not directly related to the question of PDO and how to best get the vendors involved. Once we've figured that out, we can iron out the details of the implementation. I think if we did this it would have to be as part of a broader approach, with a full re-evaluation of the PHP/PECL relationship, some hard thinking about distribution mechanisms for PECL, and some serious decisions about setup recommendations. It's really not the quick fix it appears to be... and making it so without putting that effort into it would hit the PHP userbase harder than anyone else. And that's well beyond the scope of PDO. Remember, one of the concerns raised by the community was that this business would interfere with the rest of PHP; the suggestions we've made so far have been intentionally very focused to avoid getting into that. Again; first let's see if we can find an acceptable way to take their contributions before moving on to those finer points. BTW I'm still waiting to hear about the other alternatives that were discussed behind our backs, and the objections against them... and I say 'behind our backs' simply because nobody seems to want to tell us! We talked about whether the various vendors could work on various combinations of pieces of the code if they were or were not CLA'd. I'm sure you don't really need me to list the various combinations of CLA, not CLA, in PHP, in PECL, outside of PHP, and hosted individually by the vendors. It was not a very exciting discussion. The main realization was that the vendors could not co-operate with each other on code without a CLA in place, and that some of them would not be able to co-operate with the community without a CLA in place. --Wez. Best regards, Marcus -- PHP Internals - PHP Runtime Developme
[PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
If we're going the PECL refurbishment route, can we have some way of marking non-standard (as in CLA'd or differently-licensed) extensions to make contributors' lives easier and future discussions of this nature moot? Possibly even a separate CVS module that hooks into the PECL infrastructure? e.g. PECLA ? :) This seemed a bad idea to me last night, but actually it could work out well (assuming PECL itself is sorted out pronto). From the end user perspective there'd be no distinction between PECL and PECLA extensions - both would have pecl.php.net homepages and releases etc - but from the dev perspective there's this whole marked area that you know you're going to need to sign something if you want to contribute to it, and it would require a separate checkout. It also has the advantage that we don't need to wait for PECL to be fixed before opening up the repository module, although obviously how well it works would be down to how well PECL resolves its problems. Thoughts, anyone? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
On Feb 2, 2008 3:14 PM, Wez Furlong <[EMAIL PROTECTED]> wrote: > Pierre, > > At no point have I or anyone else said that the future of PDO depends > on a CLA. > > --Wez. No, you did not say it explicitally. However you said that many vendors, experts or leaders will not contribute or will not support PDO if there is no CLA in place. Many persons interpret it as: PDO will not support any proprietary databases if we don't have a CLA, or will stop to support them (because the vendors will not contribute). That's simply not true and I do think that we should clarify this point. That's what I said in my reply to Richard. It is also wrong to say that they can't contribute without CLA while they do contribute already in all possible ways. The more I think and read about this topic the more I think that the only companies or persons looking for CLA in php are you. Neither IBM or Oracle stopped to contribute. Microsoft never actually contributed to PHP directly but that did not prevent them to work on their FCGI implementation for IIS and it works very well. MySql does not need it, Postgresql neither... -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
Hello Steph, all we need is to extend the PECL database with a license type field and a CLA flag. Nothing else is required at that end. But we should still move as much from php-src/ext to pecl as we can. marcus Saturday, February 2, 2008, 6:36:23 PM, you wrote: >> If we're going the PECL refurbishment route, can we have some way of >> marking non-standard (as in CLA'd or differently-licensed) extensions to >> make contributors' lives easier and future discussions of this nature >> moot? Possibly even a separate CVS module that hooks into the PECL >> infrastructure? > e.g. PECLA ? :) > This seemed a bad idea to me last night, but actually it could work out well > (assuming PECL itself is sorted out pronto). From the end user perspective > there'd be no distinction between PECL and PECLA extensions - both would > have pecl.php.net homepages and releases etc - but from the dev perspective > there's this whole marked area that you know you're going to need to sign > something if you want to contribute to it, and it would require a separate > checkout. > It also has the advantage that we don't need to wait for PECL to be fixed > before opening up the repository module, although obviously how well it > works would be down to how well PECL resolves its problems. > Thoughts, anyone? > - Steph Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
all we need is to extend the PECL database with a license type field and a CLA flag. Nothing else is required at that end. But we should still move as much from php-src/ext to pecl as we can. Hm but then when you checked out you'd have CLA'd stuff as well as normal PECL stuff, as now. Don't you find you automatically tend to fix things if they're broken? I know I do... even if I rarely get around to posting those fixes (because once everything works here I go on to the stuff I wanted to do and forget there was even a problem, until the next time.) I was just trying to find a way that would be acceptable to php.net and also would mean PDO2 driver development doesn't have to wait on PECL process decisions, but actually my off-list feedback says even a PECLA module wouldn't be an acceptable option for some. - Steph marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Writing PHPT tests
You simply ignored my email or never got it? The correct place for such scripts
is not in the "root" but in scripts/dev/
--Jani
zoe kirjoitti:
Hi - for any of you that are writing PHPT tests for existing extensions
- I put a PHP script called generate_phpt.php into PHP 5.3 yesterday
which might help a little.
It's quite a simple command line script (Raghu and I wrote it last
year), it works by looking at the {{{proto line for a function in PHP
source code and construct a test case frame from it. It can be used to
construct very simple tests cases - or to turn an existing PHP file into
PHPT format. It doesn't try and guess what the results of a test should
be :-). I will document it properly on qa.php.net later. In the meantime:
php generate_phpt.php --help
tells you what it's supposed to do.
Zoe
PS - It doesn't work for PHP6 right now because the {{{proto line is
different.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] An Idea for PDO 2
Pierre, since you choose to ignore the mails I sent to your "secret" address, I'm taking this to the list, maybe this will be noticed: Pay what you owe me! --Jani Pierre Joye kirjoitti: Hi, On Feb 2, 2008 12:15 PM, Richard Quadling <[EMAIL PROTECTED]> wrote: If there is no CLA, will that mean we will not get the PDO 2 drivers we need to be able to communicate with the databases? It would be really nice if the pro CLA camp stops to condition the existence of PDO (or its future) to the CLA acceptation. That's simply wrong. Oracle, IBM and MySql (which states their point already, they will accept the choice made by the php project) contribute already to php. The question is actually: Can they continue to ignore PHP or do they have to have their respective products working smoothly with PHP? The answer is pretty obvious and we see announces on a regular basis to proove they have to support PHP. Read the respective interviews or stories about PHP, the tone is completely different now than a year ago. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Splitting the subject: the PECL/PHP relationship
Hi all, Just so's Marcus and I don't have to keep cross-posting here... The problems of PECL vs core extensions are many, and exist with or without the PDO/CLA debate. Marcus (among others) says he wants to get as many extensions as possible out of the core and into PECL. I agree fully with this as a long-term aim, but feel strongly that the PECL infrastructure is not equipped to support it well at present. 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access to their own php.ini they still can't do much with those extensions. So we have to seriously consider how to recommend extensions to hosts, other than by shipping them with the PHP core. 2) Maintenance status needs to be part of the equation. 3) Stability needs to be part of the equation. 4) Appropriateness to a given PHP branch needs to be part of the equation. 5) CS and documentation need to be part of the equation. Thoughts? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
Hi, On Feb 2, 2008 8:52 PM, Steph Fox <[EMAIL PROTECTED]> wrote: > > all we need is to extend the PECL database with a license type field and > > a > > CLA flag. Nothing else is required at that end. But we should still move > > as > > much from php-src/ext to pecl as we can. There is no place for CLA in pecl either. I still see zero reason to tolerate CLA in pecl.php.net or anywhere else. > I was just trying to find a way that would be acceptable to php.net and also > would mean PDO2 driver development doesn't have to wait on PECL process > decisions, but actually my off-list feedback says even a PECLA module > wouldn't be an acceptable option for some. It is not OK for me (to list one). The last attempt to create this exact solution (flag in pecl with automatic download of pdf to sign etc.) was sadly a failure. As it begins well, the communication between the company and us was not good at all and it was not possible to get answers in a reasonable time or simply no answer at all. Wez was also involved and was the initial contact between the company and php. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
On Feb 2, 2008 9:14 PM, Steph Fox <[EMAIL PROTECTED]> wrote: > Thoughts? It is also possible to have both. It is even a good thing for what linux distributions told me about zip. About moving all extensions to PECL, we already discussed this problem and the conclusion was to continue like now. There was good reasons listed. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Steph Fox wrote: Be fair, this is an open list. Anyone can join it, and it keeps the noise levels down on [EMAIL PROTECTED] Please? ;) http://news.php.net/php.pdo Move all of PDO over to there and let those of us who have not found any reason to need to switch to it get on with fully open source development :) Perhaps if PDO actually added some value there there would not be a problem, but we still need something sensible wrapping it to make cross database SQL work so why do I need to bother changing the internals of what I have been working with for years just to 'fix half of the problem' with a solution at is still showing a significant decrease in performance over native drivers managed transparently in ADOdb. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
Hello Steph, you would not checkout php-default. That would only be used for release management. Instead you would checkout php-src and whatever pecl modules you wanted, just as you do today. And that includes that you can choose whether you like CLA modules or not. Just as today you do not get all PECL modules. marcus Saturday, February 2, 2008, 8:52:44 PM, you wrote: >> all we need is to extend the PECL database with a license type field and >> a >> CLA flag. Nothing else is required at that end. But we should still move >> as >> much from php-src/ext to pecl as we can. > Hm but then when you checked out you'd have CLA'd stuff as well as normal > PECL stuff, as now. Don't you find you automatically tend to fix things if > they're broken? I know I do... even if I rarely get around to posting those > fixes (because once everything works here I go on to the stuff I wanted to > do and forget there was even a problem, until the next time.) > I was just trying to find a way that would be acceptable to php.net and also > would mean PDO2 driver development doesn't have to wait on PECL process > decisions, but actually my off-list feedback says even a PECLA module > wouldn't be an acceptable option for some. > - Steph >> marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
Hello Pierre, amen!, You're noted as no. But other people see a reason and continue to discuss *please* without you. We will take your vote in as no when it comes to voting if ever. If you are interested in explanations then I suggest you read all mails and blogs again until you understand the reason why some peole need a CLA. marcus Saturday, February 2, 2008, 9:33:13 PM, you wrote: > Hi, > On Feb 2, 2008 8:52 PM, Steph Fox <[EMAIL PROTECTED]> wrote: >> > all we need is to extend the PECL database with a license type field and >> > a >> > CLA flag. Nothing else is required at that end. But we should still move >> > as >> > much from php-src/ext to pecl as we can. > There is no place for CLA in pecl either. I still see zero reason to > tolerate CLA in pecl.php.net or anywhere else. >> I was just trying to find a way that would be acceptable to php.net and also >> would mean PDO2 driver development doesn't have to wait on PECL process >> decisions, but actually my off-list feedback says even a PECLA module >> wouldn't be an acceptable option for some. > It is not OK for me (to list one). The last attempt to create this > exact solution (flag in pecl with automatic download of pdf to sign > etc.) was sadly a failure. As it begins well, the communication > between the company and us was not good at all and it was not possible > to get answers in a reasonable time or simply no answer at all. Wez > was also involved and was the initial contact between the company and > php. > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
Hello Steph, what I want is php-src as minimum you can depend on. And php-default as release managers playground. The RM can then say what he thinks is mature enough to make it into a release. marcus Saturday, February 2, 2008, 9:14:12 PM, you wrote: > Hi all, > Just so's Marcus and I don't have to keep cross-posting here... The problems > of PECL vs core extensions are many, and exist with or without the PDO/CLA > debate. > Marcus (among others) says he wants to get as many extensions as possible > out of the core and into PECL. I agree fully with this as a long-term aim, > but feel strongly that the PECL infrastructure is not equipped to support it > well at present. > 1) Distribution woes need to end. With the work Greg's been doing lately on > PHP_Archive/Phar, that's very close to being attainable now in the physical > 'getting PECL'd extensions out to people' sense, but unless people are > running CLI or CGI or have access to their own php.ini they still can't do > much with those extensions. So we have to seriously consider how to > recommend extensions to hosts, other than by shipping them with the PHP > core. > 2) Maintenance status needs to be part of the equation. > 3) Stability needs to be part of the equation. > 4) Appropriateness to a given PHP branch needs to be part of the equation. > 5) CS and documentation need to be part of the equation. > Thoughts? > - Steph Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
Hello Pierre, basically you are saying that zip would not have been used by anybody if you hadn't forced us by mail bombardment to include it. So now I am wondering why you care so much what goes in and what goes out? After all it is the RMs decision. And we might get asked or not. marcus Saturday, February 2, 2008, 9:38:04 PM, you wrote: > On Feb 2, 2008 9:14 PM, Steph Fox <[EMAIL PROTECTED]> wrote: >> Thoughts? > It is also possible to have both. It is even a good thing for what > linux distributions told me about zip. About moving all extensions to > PECL, we already discussed this problem and the conclusion was to > continue like now. There was good reasons listed. > Cheers, > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
On Feb 3, 2008 12:18 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > Hello Pierre, > > amen!, You're noted as no. But other people see a reason and continue to > discuss *please* without you. Sorry, are you saying that the discussions are restricted to only a few chosen? All your arguments in your recent posts about openness and transparent process are rather pointless now. You may be pragmatic, but for your convictions, there is room for improvements. > We will take your vote in as no when it comes to voting if ever. And now you consider that discussions about what will happen in php.net, pecl.php.net and php core can happen suddenly in a newly created list and some people does not have to participate or are not welcome. What a wonderful example of what you have in mind for the future of the php.net projects and how they should work. > If you are interested in explanations then I suggest you > read all mails and blogs again until you understand the reason why some > peole need a CLA. Blog posts are not the way we communicate within a project sorry. All mails I read did not give reasons why a CLA is required for us and what benefits we will get. All one can read is only about external entities not able to contribute because the lack of CLA, absolutely no details about who they are, what are their real needs and expectations . The biggest problem is that they did not think that informing us via the normal way would have been expected. If the process was transparent and if all parties were actually discussing it then yes, I would have been more open and even helped to provide the tools in the pecl web site or in other parts of our sites. But how it goes, it is more the perfect example of a complete opaque process and confirm everything we can think about such additions. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
On Feb 3, 2008 12:22 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > basically you are saying that zip would not have been used by anybody if > you hadn't forced us by mail bombardment to include it. What are you talking about? I post one proposal and it was accepted after the only issue was resolved (which was a long discussions). You are getting ridiculuous with your attacks Marcus, and I stay polite. And no, it is not the RM decisions to choose what goes in or out, despite your changing opinions about open source, openness and PHP.net. > So now I am > wondering why you care so much what goes in and what goes out? After all it > is the RMs decision. And we might get asked or not. What I was refering to is the possibility to have releases via pecl.php.net and official PHP releases, on a regular basis. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
Hello Pierre, I spoke about you as you left no room for discussions. You are not willing to compromise in any way, nor are you willing to be productive in any way. So there is no way in keeping you in discussions, is there? And no, we are no having any closed discussions. But we are having discussions because we want progress, productivity and we like to get more help. marcus Sunday, February 3, 2008, 12:51:03 AM, you wrote: > On Feb 3, 2008 12:18 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Hello Pierre, >> >> amen!, You're noted as no. But other people see a reason and continue to >> discuss *please* without you. > Sorry, are you saying that the discussions are restricted to only a > few chosen? All your arguments in your recent posts about openness and > transparent process are rather pointless now. You may be pragmatic, > but for your convictions, there is room for improvements. >> We will take your vote in as no when it comes to voting if ever. > And now you consider that discussions about what will happen in > php.net, pecl.php.net and php core can happen suddenly in a newly > created list and some people does not have to participate or are not > welcome. What a wonderful example of what you have in mind for the > future of the php.net projects and how they should work. >> If you are interested in explanations then I suggest you >> read all mails and blogs again until you understand the reason why some >> peole need a CLA. > Blog posts are not the way we communicate within a project sorry. All > mails I read did not give reasons why a CLA is required for us and > what benefits we will get. All one can read is only about external > entities not able to contribute because the lack of CLA, absolutely no > details about who they are, what are their real needs and expectations > . The biggest problem is that they did not think that informing us via > the normal way would have been expected. > If the process was transparent and if all parties were actually > discussing it then yes, I would have been more open and even helped to > provide the tools in the pecl web site or in other parts of our sites. > But how it goes, it is more the perfect example of a complete opaque > process and confirm everything we can think about such additions. > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2
Personally I do a full pecl checkout alongside my php-src checkout, every time. The problems with that tend to come out during the build. - Original Message - From: "Marcus Boerger" <[EMAIL PROTECTED]> To: "Steph Fox" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "internals" Sent: Saturday, February 02, 2008 11:16 PM Subject: Re: [PDO] Re: [PHP-DEV] Fw: [PDO] [RFC] An Idea for PDO 2 Hello Steph, you would not checkout php-default. That would only be used for release management. Instead you would checkout php-src and whatever pecl modules you wanted, just as you do today. And that includes that you can choose whether you like CLA modules or not. Just as today you do not get all PECL modules. marcus Saturday, February 2, 2008, 8:52:44 PM, you wrote: all we need is to extend the PECL database with a license type field and a CLA flag. Nothing else is required at that end. But we should still move as much from php-src/ext to pecl as we can. Hm but then when you checked out you'd have CLA'd stuff as well as normal PECL stuff, as now. Don't you find you automatically tend to fix things if they're broken? I know I do... even if I rarely get around to posting those fixes (because once everything works here I go on to the stuff I wanted to do and forget there was even a problem, until the next time.) I was just trying to find a way that would be acceptable to php.net and also would mean PDO2 driver development doesn't have to wait on PECL process decisions, but actually my off-list feedback says even a PECLA module wouldn't be an acceptable option for some. - Steph marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
Hi Marcus, what I want is php-src as minimum you can depend on. And php-default as release managers playground. The RM can then say what he thinks is mature enough to make it into a release. What _I_ want is a PHP core that is really core. By that I mean things like: date, spl, pcre, zlib, filter, simplexml, core-ish stuff such as PDO (no PDO drivers, unless we bundle SQLite as we could/should IMHO so there's a working DB for all), and underlying libs like libxml and mysqlnd that will make life easier for the many. I think what is distributed with PHP should be built-in and enabled by default, and it should include the basic essentials for making a simple website without anything else being added - and nothing more. Everything else - the fashionistas (JSON, xmlreader/writer) and the downright useful for some but not all (fileinfo, json, com_dotnet, posix) and the quirky stuff (pretty much anything Sara came up with) - should be in PECL. A release managers playground? Maybe we should look at PHP core + a 'recommended' PECL release that ships with it, and refer everyone to pecl.php.net/pecl4win.php.net for anything else. This assuming the problems I listed earlier are dealt with, natch. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
