Re: [PHP-DEV] Lists
This has probably been mentioned before, but I think the naming of php-dev is way misleading. It's funny that people get so ripped when someone sends an off-topic question to this list. Someone who doesn't read the descriptions may very well take php-dev to mean PHP development. This is ambiguous; it doesn't make any distinction between developing with php and developing the language itself. Whining about people not reading the descriptions won't change it; get over it. Before taking a huge step like making the list moderated or (gasp!) subscription only, why not just rename the list to something less inviting to people who either a) don't care to read the list descriptions or b) have a poor grasp of English/programming and don't comprehend the difference. php-evo (php evolution)? php-int-design php-improvement php-future I know all of these are corny and stupid; they are the product of 5 seconds of thought. I'm sure a better end result could be gained with more thought. But even these are much more likely to appeal less to people looking for the general (or whatever) list. John On Tue, 5 Feb 2002, Rasmus Lerdorf wrote: I completely agree with Dan on these points. If you don't want to see certain types of posts, or posts from certain people, you are a simple procmail rule away from getting rid of them. Making php-dev a closed list is a horrible idea. -Rasmus On Tue, 5 Feb 2002, Dan Kalowsky wrote: On Wed, 6 Feb 2002, James Cox wrote: I ask a simple question: how many more unsubscribed hard working developers does it take before we realise that we need to ban certain people, and make php-dev (or it's brother) subscribers only, and closed subscription? Umm while this sounds like a good idea initially, why are you trying to make PHP a closed development project? This maneuver will make it lots more difficult to get any new developers in on the project, and for those with one time questions to pose them. A moderated list might be a feasible option, but by making a closed subscrition system you basically end the open source project ideal. - We need a place for developer discussion which is not interupted by users who can't read the support guidelines. Yes this is a problem in almost every project. You can read many lists and find the same problem. There is no answer to this. - We need respite from certain individuals who are not helping PHP, but instead turning good developers away. There are killfilies for this very reason. - We need to have a list that is not full of bugs junk and cvs junk - something for plain developer discussion. I disagree with this too. While the bug notifications are annoying, they provide at least an oppertunity to have more developers see them. Thats the best chance given to the project to keep the bug count down. Be honest, how many people write bug free code, or more specifically test on platforms other than their primary development choice? Not many. A big -1 on this suggestion. --- Dan KalowskyTonight I think I'll walk alone. http://www.deadmime.org/~dankI'll find soul as I go home. [EMAIL PROTECTED]- Temptation, New Order -- John Donagher Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Nested comments
On Wed, 28 Nov 2001, Andi Gutmans wrote: I agree. We should fix problems but people have to remember that no matter what there are lots and lots of users out there and the less we break things, even between major versions, the easier possible the transition will be for the users. Sometimes you need a revolution before you can have evolution. PHP is a good language for a lot of applications, but I'm not sure I would pick it for my next big project anymore. This isn't intended as a slight, just some feedback; but the language doesn't appear to be evolving to encourage quality development the way that Python has. Following this list for a long time leads me to believe that the ideal of maintaining backwards compatibility is one of the big reasons why (concern about execution speed being the other big reason, something I've always been impressed with with the PHP developers). John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Patch: Nested comments
On Wed, 28 Nov 2001, Robinson, Mike wrote: BC may not be of grave concern to Python developers. Perhaps thats why it hasn't hit the radar screens. You don't get to 6.5 million domains and a million ip addresses chomping big 'BC' pieces off of developers butts. Two completely different user domains; you can't measure Python usage by mod_python installs. Just like you can't measure Perl usage by mod_perl installs. Tthere is nothing wrong with evolution, nor revolution, provided it's carefully thought out, and executed for a reasonable purpose. Nested comments isn't it. Oh, agreed, my comment was directed towards the general attitude as opposed to the validity of this one particular patch. John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Patch: Nested comments
Sorry, why can't you do that in php?
On Tue, 27 Nov 2001, Adam Wright wrote:
But in C, you can #if 0 whole blocks out regardless. I'm in favour of a
change like this (if not this specific one) in 4.2.
adamw
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: Anders Johannsen [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, November 27, 2001 5:21 PM
Subject: Re: [PHP-DEV] Patch: Nested comments
I don't think this should be changed and we should stick to the way it is
in C. (It is also not BC and even if I thought it's a good idea, which I
don't, I don't think it's worth it).
Andi
At 11:48 AM 11/27/2001 +0100, Anders Johannsen wrote:
This patch allows for nested 'C-style' comments, which can be useful
especially while debugging.
?php
/* comments
/* now /* nest */ */
/*/*/*/*
*/*/*/*/
*/
?
Since comments are handled purely lexical, there should be virtually no
performance hit.
The following two examples show how errors are handled:
1)
?php
/*
*/
*/
?
2)
?php
/*
/*
*/
?
Ad 1) This will yield a zend_error(E_COMPILE_ERROR,Invalid nesting of
comments) on the
last line. Unpatched, a parse error is the most likely result.
Ad 2) A zend_error(E_COMPILE_WARNING, unterminated comment starting line
%d, CG(comment_start_line)) is raised.
The attached patch is against latest CVS
Best regards,
Anders Johannsen
--
[EMAIL PROTECTED]
Index: zend_globals.h
===
RCS file: /repository/Zend/zend_globals.h,v
retrieving revision 1.80
diff -u -r1.80 zend_globals.h
--- zend_globals.h 2001/10/23 01:19:16 1.80
+++ zend_globals.h 2001/11/27 10:08:06
@@ -82,6 +82,7 @@
int comment_start_line;
char *heredoc;
int heredoc_len;
+unsigned int comment_nest_level;
zend_op_array *active_op_array;
Index: zend_language_scanner.l
===
RCS file: /repository/Zend/zend_language_scanner.l,v
retrieving revision 1.40
diff -u -r1.40 zend_language_scanner.l
--- zend_language_scanner.l 2001/09/22 00:06:27 1.40
+++ zend_language_scanner.l 2001/11/27 10:08:07
@@ -1,5 +1,4 @@
%{
-
/*
+--+
| Zend
Engine |
@@ -125,6 +124,7 @@
{
CG(heredoc) = NULL;
CG(heredoc_len)=0;
+ CG(comment_nest_level)=0;
}
@@ -1057,24 +1057,39 @@
}
}
+ST_IN_SCRIPTING*/ {
+ zend_error(E_COMPILE_ERROR,Invalid nesting of comments);
+}
+
ST_IN_SCRIPTING/* {
CG(comment_start_line) = CG(zend_lineno);
BEGIN(ST_COMMENT);
+CG(comment_nest_level) = 1;
yymore();
}
-
-ST_COMMENT[^*]+ {
+ST_COMMENT[^/*]+ {
yymore();
}
+ST_COMMENT/* {
+CG(comment_nest_level)++;
+yymore();
+}
+
ST_COMMENT*/ {
- HANDLE_NEWLINES(yytext, yyleng);
- BEGIN(ST_IN_SCRIPTING);
- return T_COMMENT;
+CG(comment_nest_level)--;
+
+if (CG(comment_nest_level) == 0) {
+HANDLE_NEWLINES(yytext, yyleng);
+ BEGIN(ST_IN_SCRIPTING);
+ return T_COMMENT;
+} else {
+ yymore();
+}
}
-ST_COMMENT* {
+ST_COMMENT*|/ {
yymore();
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
John Donagher
Application Engineer, Intacct Corp.
Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] implementing posix_setrlimit
Hello- We are planning on implementing posix_setrlimit() as a sister function to posix_getrlimit() to: a) protect against runaway/buggy programs from bringing the server down and b) to allow a program that genuinely requires a lot of CPU time and/or memory to ask for it (by modifying its soft limit all the way up to an administrator-imposed hard limit) Is there any particular reason than this has not already been implemented, and if not, would it be a valid contribution to the PHP language? Thanks John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] implementing posix_setrlimit
Hi Jason- We haven't yet implemented it nor have we looked in depth at the possible intricacies of an implementation .. but from a high level we think it does make sense even then, since this is a system call that any UNIX process should be able to utilize. In any event, it only makes sense for us in an ISAPI context, as that is the context in which our application runs. There was a thread a few years ago about a possible setrlimit() implementation, but it was deferred since there is an option for setting some process limitations at the webserver level .. unfortunately those aren't enough for us. Thanks John On Tue, 2 Oct 2001, Jason Greene wrote: John, I would guess that the reason it was never implemented was due to the problems this could pose as a webserver module. If you would like to submit your patch, make sure you limit the function to the CGI SAPI. (or you can just send the patch and someone can add that) -Jason - Original Message - From: John Donagher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 3:27 PM Subject: [PHP-DEV] implementing posix_setrlimit Hello- We are planning on implementing posix_setrlimit() as a sister function to posix_getrlimit() to: a) protect against runaway/buggy programs from bringing the server down and b) to allow a program that genuinely requires a lot of CPU time and/or memory to ask for it (by modifying its soft limit all the way up to an administrator-imposed hard limit) Is there any particular reason than this has not already been implemented, and if not, would it be a valid contribution to the PHP language? Thanks John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/ircg README.txt
On Mon, 20 Aug 2001, Derick Rethans wrote: Besides IRCG, there are more extensions that are very special (like the credit card extensions, and IMO they should be moved to PEAR too. But as IRCG is indeed very special and only works met thttpd AFAIK, it definitely should belong in PEAR. Processing payments on the internet is very special? No wonder so many businesses went under in the last few months. I think as long as PHP is a viable language for ecommerce development and hosting companies these extensions (Cybercash,pfpro,CCVS) make a lot of sense to have as part of the distribution. I'm not sure I've ever seen a clear argument as to why they don't. John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/ircg README.txt
On Mon, 20 Aug 2001, Sterling Hughes wrote: I see no reason to put them in at the language level -- PEAR seems a suitable place for the extensions (once pear is setup). They're not really used that commonly (from what I can see). Also, these extensions are not the only way to process payments with PHP, plenty of sites do it different ways (I processed payments with PHP before these extensions existed). I'm not sure it's fair to say that something isn't used commonly when the awareness level and the length of time the extension has been in (stable) existance is rather small. I also processed payments with PHP before these extensions existed, but that doesn't preclude their use in the future. Much consolidation has already taken place in the online payments arena, and the libraries have matured quite a bit, supporting much more interesting things than can be done with a cross-posting HTML form. Anyway, what Zeev says is correct, if the extra 100KB is reason enough, there is no reason they can't be shipped seperately, as long as the pear utilities are rather transparent to the user. If this is the case, I would venture to say that most database extensions should also be shipped seperately, with two or three exceptions. John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora and CVSWeb problems
On Sun, 19 Aug 2001, Hojtsy Gabor wrote: Someone reported a Chora error at [EMAIL PROTECTED] It seems he uses Konqueror, and Chora can't find the default language file to display for him: | Warning: Undefined index: defaults | in /usr/local/www/chora.php.net/horde/lib/Lang.php on line 42 | | Warning: Cannot add header information - headers already sent by | (output started at /usr/local/www/chora.php.net/horde/lib/Lang.php:42) | in /usr/local/www/chora.php.net/horde/lib/Lang.php on line 64 | | [snip] I reported that last night .. seems to work fine again now. -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Output Compression Issues
On Wed, 15 Aug 2001, Rasmus Lerdorf wrote: But a second call to Header(Content-Encoding:) will replace the first one. If no content has gone out yet, overwriting a previous Content-Encoding header is trivial. I am not sure what you mean when you say that this doesn't do the job for some browsers. Do they not like a blank content-encoding header? It's not like you end up sending two content-encoding headers. Yea, we tried, it looks like some defaults are assumed if an empty Content-Encoding header is present. I'll have to confirm this tomorrow. We could add some sort of UnHeader() function which calls Apache's ap_table_unset() function, but I am not sure if other SAPI backends have support for this. That would probably have a lot of uses, and would solve our problem. Still, semantically, it seems like when output buffering is aborted with an ob_end_clean(), the headers that ob_gzhandler sets should be as well, although I guess that's rather difficult if people start writing their own output buffering handlers.. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Linux Today Article
On Wed, 15 Aug 2001, Edin Kadribasic wrote: Maybe Zend has some feedback from their enterprise clients on what features are requested, etc. It would be great to hear if anyone else has had a chance to play with the new Microsoft toys. As a PHP contributor and long-time user, I can say that if our company was starting over right now, .NET would win hands down in terms of suiting our needs (engineering-side), as a web application development company. This wasn't the case with a Java application framework, many of which were available when our company was choosing its platform. PHP has some advantages over a language like C#. However, my impressions from following this list for the last year have been that it is not being evolved towards medium-to-large application builders, but still towards people writing web sites or simple scripts. We're trying to change this with binarycloud, but still, we're spending countless hours reinventing what ASP.NET would give you for free (or rather in exchange for selling your soul to microsoft). I don't mean to be unfair. Breaking backwards compatibility would be required in many many cases in order for PHP to evolve in that sense, and as long as most people don't want it to happen, it probably shouldn't happen. That's a significant cost to incur and something new frameworks/languages don't have to worry about. John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Linux Today Article
On Wed, 15 Aug 2001, Brian Moon wrote: Could someone please tell me what other then marketing speak that .NET has on PHP? I guess I just don't see it. I mean, yeah, if you want to develop junk at a fast pace you can use MS products. I was a VB programmer for years. I know the reliability and performance cost of doing things the MS way. I just don't get it. It is all 1's and 0's. .NET doesn't have anything on PHP, anymore than .NET has anything on Python or Java or C. I'm not talking about developing in VB, or directly on an MS platform, either. I definetly don't want to start a war (there have been enough of those on this list the last few days :)), so I'll just suggest that you read [http://www.ximian.com/tech/mono-index.php3] and spend some time on msdn reading about it, instead of writing it off as marketing speak, and we can continue this off-list. -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Output Compression Issues
We've run into some trouble with output compression, specifically when using
PHP to generate PDF's, and send them directly to the browser with an overridden
mime-type. It appears as though the browser support for this is rather lame;
even recent versions of Netscape hand Acrobat the compressed version of the
PDF, and Acrobat chokes, really badly. Some relatively recent versions of IE
also have problems dealing with compressed non-HTML content.
So, we really want to disable output compression when we are serving anything
but HTML/text. Easy enough. We simply wrap calls to header() with our own
function that looks at the Content-Type that people are sending, and turn off
output buffering if necessary. But what we've been bitten by is the inability
to completely turn off output compression once it has been turned on with
obstart(ob_gzhandler).
ob_end_{clean,flush} will stop the output buffering and compression, but the
header 'Content-Encoding: gzip' is already sent, at that point. Since we can't
(to my knowledge, please correct me if this is the case) remove the header, the
best we can do is replace it with the second header() parameter, which
unfortunately doesn't do the job as far as the browsers are concerned.
Two ideas:
-we could change zlib.c to, when output buffering+compression is on, not call
sapi_add_header (with the Content-Encoding header) until a ob_end_flush happens
or the buffer is flushed implicitly at the end of program's execution. If an
ob_end_clean were to happen, the header is not sent at all. That seems like
more correct behavior, but someone more familiar with the code will have to
speak to the feasibility of this.
or
-write an extension wrapping the appropriate Apache API calls so that one, from
PHP, can manipulate (read: delete) the headers in Apache's output buffer, like
you can in Perl. My guess is that this probably would already have been done if
there were not some significant obstacles.
Thoughts?
--
John Donagher
Application Engineer, Intacct Corp.
Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] transparent output compression
Hi all- Is there really a difference between ob_gzhandler and zlib.output_compression, now that ob_gzhandler supports chunks? Since, in zlib.c, zlib.output_compression still causes output buffering to be turned on, I can't see that there's a convincing reason to use one over the other, unless you need fine control over the flush/clean functions. Can anyone shed some light on this? Slightly OT: with such an amazing option so easy to implement on top of an existing application (via either PHP or mod_gzip), and widespread browser support, why don't more sites use this? Bandwidth is expensive. CPU cycles are not. We've seen 900K HTML reports compressed to 40K. Truly awesome. Thanks John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
On Wed, 15 Aug 2001, James Moore wrote: RFC.. Request For Comments, its as simple as that someone posts a document outlining what they want changed/want to do, calls it an RFC and is litterally making a request for comments on their idea. I think this is a good idea for large things but if we encourage too much we will suddenly be flooded with RFC's all over the place then they begin to conflict.. I think that if someone feels somthing is really important then an RFC is a good idea but I certainly dont want a couple a week to plough through. With what end in mind is an RFC to be created for? In the IETF, RFC's are typically long, complex, and authoritative. They are often referenced for years after their inception. Do you honestly think we could (or want to) achieve this with PHP feature RFC's? Or will they be used only before initial feature implementation, then quickly outdated and discarded? That is my biggest problem with documents: they take a lot of effort to create, are often difficult to grok, and _almost always_ have a very short lifecycle. -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Writing php modules in C++
Take a look at some of the extensions in the source code that are written in C++. John On 8 Aug 2001, Shao Zhang wrote: Hi, I cannot find any information on writing the php external module in C++ or any other languages other than C. Basically I need to develop an external php module to interface with some other third party library which is only available in C++. Could someone point me somewhere to start? Regards, Shao. -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Fri, 27 Jul 2001, Zeev Suraski wrote: It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; And yes, I have run across code like this. If somebody wants to shoot himself in the head, he's quite welcome to do it. But when you hand a gun over to somebody, you don't point it at his head, but safely hand it to his hands. What he does afterwards is his own business (assuming he doesn't come after you :) I think Rasmus is right. We've been shooting the guy in the head for the last few years while register_globals was/is on. People incorporating other PHP libraries like Horde/PHPLIB (just examples) and what have you, will immediately break, even after they fix their own code, the third party libraries will still be broken. This means that the library maintainers will be under significant pressure to release a patch; fixing the code to use a safer method of accessing user data. My guess is the above patch is what will make it in, not because the guy doesn't understand it's bad, but he was already shot in the head by the default php.ini setting and so he's not really _losing_ anything now. -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] === Question
Check out: http://www.php.net/manual/en/language.operators.comparison.php Also, this list is for the development of the language, not development with the language. You probably want to be at php-general. John On Thu, 19 Jul 2001, Patrick Pease wrote: What does the === operator do and whats the difference between == and ===? any help? Thanks Patrick PEase -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] include *.php
On Fri, 13 Jul 2001, Hartmut Holzgraefe wrote: Martin Pedak wrote: What people think about adding regular expressions to include() or require() constructions or even making new language consruction like import() that can handle reg. exp. file includes. So thant you can include(/my/path/*) or import(/my/path/*.php). You seem to be thinking about something like the import mechanism in Java, aren't you? While this is a nice feature for a compiling language it does not make to much sense for a scripting environment where every included file will hurt runtinme performance and where this 'feature' could be used for attacks by putting additional files in import-directories. If you really still want this feature you can always use readdir() and friends to implement the requested behavior in userland This is more or less what we did in binarycloud. We've created the notion of packages and somewhat of a hierarchical namespace in userland. It works really well, although the usefulness would probably be lost on small applications or scriptlets. Other than possibly making import into a language construct as opposed to a function, and having the the engine do the package management, which is more convenience than anything else, we haven't found much reason to implement this in the language. www.binarycloud.com if you're interested. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] NGScan - technical explanation
On Mon, 9 Jul 2001, Zeev Suraski wrote: At 21:49 9/7/2001, Sascha Schumann wrote: On Mon, 9 Jul 2001, Zeev Suraski wrote: So have a patch on your directory as you published it, for those few for which the flex scanner doesn't work (and they *are* very few). Don't break PHP. Could you explain to me how a completely optional change which people need to enable explicitly can break PHP? Abstracting the scanner interface, and putting it into PHP, breaks the whole structure of PHP. Would it work? Of course, I trust you tested it. A lot of things that would work are things that are wrong, and that break PHP, from a structural point of view. This seems rather subjective. Also, if the Zend license will be modified (and, to everyone on this list, that is still an _if_), can't we revert back to the former, non-abstracted structure? John -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] List messages are being delayed?
Any particular reason why these have to be hosted on the same machine? There are lots of good free mailing list services out there (yahoogroups being one) that handle high traffic lists. I can definetly see the rationale behind having a dedicated machine for CVS/bugs and private mailing lists, but is that really necessary for php-general/php-dev/php-cvs etc..? John On Wed, 20 Jun 2001, Rasmus Lerdorf wrote: Rasmus (or anyone): Can you quantify what lists.php.net consumes for bandwidth on average? As long as it's not some completely outrageous figure, I can meet all of these criteria... Once you add the cvs server and the snapshots it would eat up the better part of a T1 consistently. Perhaps not quite 1.5M, but probably in the 1M range. 384K is definitely not enough just for the lists. -Rasmus -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zdnet Article
Responding to this article only prolongs its life. Treat PC Magazine/ZDNET's reviews as you would a 3rd grader's book report. These are not technical publications; they are the Popular Mechanics of the PC world. When considering languages/environments to use when building an application, very few people will read ZDNET publications to help them decide. John On Fri, 18 May 2001, Gavin Sherry wrote: There is a disappointing trend in 'mainstream' commentary on open source projects. This is an example of one. In the last year of so I have had a lot of experience with poor media coverage of projects I am either involved in or follow closely. One of the worst being an all out attack on PostgreSQL by an indian online magazine resently which seemed to be directed at an entirely different project. I think the short-comings of this article should be addressed in a civil manner. An open letter to ZDNet and the author, for example. This could be posted on the front page of php.net and would probably get coverage on places such as slashdot and perhaps ZDNet itself. I would recommend against personal and emotion emails to the author or to ZDNet as has happened in other cases. Such an open letter could be arranged on this list or by some of the top developers. I think it unfortunate that especially in the case of Open Source journalists are not doing any research -- I say especially because there is such a large amount of information and support for open source projects such as PHP. I would be happy to draft a response if everyone else would like to move in that direction. Gavin On Fri, 18 May 2001, Emmanuel FAIVRE wrote: http://www.zdnet.com/products/stories/reviews/0,4161,2711724,00.html no word to comment that ! just see a adbanner for ColdFusion on the same page ! Manu -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Classes function names
On Fri, 4 May 2001, Zeev Suraski wrote: IMHO, in a compatibility breaking upgrade, we should look into defaulting to case sensitivity, while allowing case insensitivity as a non-default option. Zeev That solves my problem and makes me happy. +1 -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.1 Declaration Case Persistance
Hi folks- I brought this up a few months ago, and due to either tacid approval or utter disinterest I was unable to spark a discussion or gather a concensus :) Right now, when a class (or method, or function) is declared, its name is zend_str_tolower()'d. This provides the case-insensitivity that PHP has, but it would be nice if the original casing on the class name was persisted so that functions like get_class would return the actual *as-declared* class name. This has a rather narrow end-user meaning for most people, but not for teams like ours who structure their code with cased filenames. The current implementation can be worked-around, I'm just not sure I see any advantage of lowercasing the declarative as opposed to just maintaining a hash of lowercase = as_declared. That would still allow for case-insensitivity while allowing the reverse-lookup functions to be more correct. Any opinions? Have I overlooked something that makes this more difficult than it seems? I'm willing to work on this if I can gather some positive concensus. -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
Hi Sterling- There are implementation-specific reasons of why this can be useful, but I was hoping to avoid the I can't see why you'd want this (very common on this list, and something I'm also guilty of, but limiting to the evolution of the language IMHO) argument in favor of semantically that's probably the right way to do it, but it's not real important, which is why I'm willing to make the change if the concensus is that the change would be the right thing. I definetly believe it's not real important and will have no visible benefit to most people. What I want to be sure of is that it won't hurt most people either. I'm not sure if the speed decrease would be noticeable. I don't get your argument about it being a kludge; I think what we have now is the kludge. I do agree a get_declared_class() would probably have a high WTF factor, which is why I favor changing the original to (like Andrei said) accept a parameter which determines its behavior. Thanks John On Thu, 3 May 2001, Sterling Hughes wrote: On Thu, 3 May 2001, Wez Furlong wrote: On 2001-05-03 22:51:41, Wez Furlong [EMAIL PROTECTED] wrote: | John Donagher [EMAIL PROTECTED] Right now, when a class (or method, or function) is declared, its name is zend_str_tolower()'d. it would be nice if the original casing on the class name was persisted so that functions like get_class would return the actual *as-declared* class name. +1 It will work, right (zend guys?). I'd love to see it. I really don't see why you would want this (correct case of class names being returned). But besides that, its not (imho) worth the speed decrease (and kludge factor) to implement. -Sterling -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.1 Declaration Case Persistance
We use a Java-style methodology of naming classes as well as filenames, something we've adopted largely because of our use of PHPDoc. So, if you have a class FooBar, that class is defined in FooBar.cls, not foobar.cls. If get_class() returned the as-declared name, we'd have a really easy way to know where that class was defined. When you start getting into complex inheritance and class dependency trees, this issue finally rears its head. Other than this case, I have never cared. So, I've had to create a code generator to build a structure containing a mapping of class declaration names pointing back to filenames, which otherwise could not be accurately programatically determined. But if you use lowercased class naming, you can programatically determine the filename. That seems wrong to me. We (at my current company) have a clean architecture, something we're working on incorporating into a currently existing open-source application framework project to allow other people to use. So yes, three users may be affected by it now (maybe less :). I really don't want to propogate the kludge I've had to write out to hundreds of people, though. Don't change the code because of me, or because of the project I'm working on, or because of the way PHPDoc works. We've already worked around it. But I still maintain that tossing away the declared names is not the only (or the best) way to achieve case-insensitivity in the language. Believe me, I wouldn't have wasted cycles thinking/writing about this if I wasn't convinced it will benefit PHP and its users in the long run, even if the value add is relatively minor. On Thu, 3 May 2001, Andrei Zmievski wrote: At 02:50 AM 5/4/01 +0300, Andi Gutmans wrote: I still don't think this is something lots of PHP users will benefit from. On the contrary, I think semantically it is more correct to define what the case insensitivity means (names are converted to lower case). How many examples can you think of where this would actually help a PHP developer? Purely cosmetically, it would be nice. For example, in PHP-GTK I have a lot of error messages that output class names, and it'd be nice to display the names as they were registered by the user/system rather than all lowercased. -Andrei -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)
On Sun, 29 Apr 2001, Zeev Suraski wrote: In order to avoid this you actually have to call it at completely different times, something you can't really guarantee. We should probably not use the timestamp as the seed (at least not alone), but also take the pid into account. Zeev That only really works for forking webservers, does it not? Another alternative would be to use microseconds... -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Database connection pooling
Mathijs- It would seem that a better model is to simply state that there are resources that would like to be persisted outside of PHP threads of execution, possibly outside of a webserver's process space, perhaps even outside of a physical machine or network. Many people will agree with you. What you're looking for would fall under the scope of an application server. You can find past discussions on this about that, from people who know far more about it than I do :) John On Sat, 10 Feb 2001, Mathijs Brands wrote: Hi all, This is my first post to this list, so please bear with me ;) Anyway, I've been running/developing a PHP application (fairly simple content management system) for some time now and it has been running pretty well. I'm using Apache 1.3.14, PHP 3.0.16 and PostgreSQL 6.5.3. The problem is that the increasing number of requests the application needs to service requires me to increase the number of Apache processes, which sometimes causes database problems. Originally I had about 10-20 running processes, but now I sometimes reach 75-100 or more. Since I'm using persistant db connections, this means I can have 100 (or more) open db connections; this is not something PostgreSQL really likes. If I use normal db connections, everything works ok, but the performance is no longer acceptable. I suspect that I only need 2-3 db connections for every 10 running processes. On another server we're running several PHP/PostgreSQL and PHP/MySQL based website, also using Apache 1.3. In this case I'm having similar problems. In order to handle the amount of traffic this webserver needs about 80-150 processes (I've seen up to 230 running httpd's). Some scripts get quite a lot faster if I use persistant connections, but if I do, I can be pretty sure that both MySQL (hangs after a while) and PostgreSQL (dreadful performance, sometimes crashes) get into trouble. I currently have 2 MySQL and 3 PostgreSQL databases, so if I have 150 running processes, I could have 300 open MySQL and 450 open PostgreSQL connections. It's like tinkering with explosives, since this is sure to cause a lot of trouble. What I'd like is a way to have a small pool of database connections with a fixed (configurable) size. When you request a persistant connection in a PHP script, you would either get a connection from the pool or a new, normal connection (if there are no more free connections in the pool). Upon closing the connection moves back to the pool or is closed in case of a normal connection. I've done some searching in the mailinglist archives and on the net and I haven't found a usable answer yet, so I'll probably look into implementing something myself (using PHP 4.0.x and PostgreSQL 7.0/MySQL 3.23). I haven't really looked at how complex this would be, but I am aware of the fact that something like this is much easier to implement for a threaded webserver. Any comments or suggestions would be really welcome, Btw. Something I'll probably do until I come up with a solution is moving all scripts requiring db access to another webserver (running on the same machine) with a much lower number of Apache processes. It solves the database problem, but introduces a whole range of new problems. TIA, Mathijs -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] wrong implementation of isset()?
On Wed, 7 Feb 2001, [ISO-8859-1] André Langhorst wrote: we should just define (and document) this similar to Andrei (note, I do not use the word "the same" I use that word equal, what means different things): NULL equals absence_of_value equals absence_of_variable_in_namespace I can imagine no case where people would need to differentiate between NULL and never been in namespace, we should not allow this, otherwise we would introduce the differentiation into a third state, non existent, what raises the wtf-factor and is not required as far as I can think andré I agree. I've watched a lot of seasoned programmers learning PHP and the behaviour of various functions operating on NULL, 0, and '' has always had an extremely high wtf-factor (I really like that term). Most of the former discrepancies have been fixed, though. Try as I might, I can't think of a good case where you'd want to check for NULL and existance in the namespace. -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] GPG extension?
I've been considering starting work on a GPG extension for PHP, similar to the Perl GPG interface (http://gpg.sourceforge.net). Anyone working on this already? John -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SSL
On 4 Feb 2001, James H. Cloos Jr. wrote:
"John" == John Donagher [EMAIL PROTECTED] writes:
John If you mean the ability to have PHP talk with an HTTPS server,
John it already exists in the form of the CURL extension.
It has been stated on the list that curl can only grab to a file, not
to php variable. Is that (still?) the case?
Not the case anymore :)
John Access to some OpenSSL APIs is provided through the experimental
John openssl extension.
Complete support for the OpenSSL API, including support for:
fopen("https://example.com/", "r")
would be a great feature to have.
(As would -- perhaps optionally -- a more complete HTTP client
implementation for fopen().)
-JimC
Agreed.
John
--
John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com
Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] FYI: pfpro extension
About a month ago Verisign released a new SDK (albeit with somewhat limited platform support) which fixes the problems previously discussed regarding using the pfpro extension inside another program which has been linked against an SSL library. You can download the new SDK from within the manager interface: https://testmanager.signio.com/Downloads/Downloads_secure.htm So at this point, the extension should be considered fully operational by anyone considering using it. Thanks to everyone who helped request this enough so that customer support stopped piping the requests to /dev/null :) John -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] http://cvs.php.net/
Looks great under Konqueror on Linux. Any plans for blame/annotate and tag searching tools like Bonsai has? John On Mon, 22 Jan 2001, Martin Jansen wrote: On Mon, 22 Jan 2001 14:04:11 -0500, Chuck Hagenbuch wrote: Quoting Martin Jansen [EMAIL PROTECTED]: Looks pretty nice. But I wonder if it is really stable: It's up to the core php guys, of course. But we (Horde) would certainly be very happy to have it used. =) Hartmut told me that it's looking not that nice under Linux, so there might be some stuff to fix before putting it on cvs.php.net :) -Martin -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnCZ1oRBACFgkFCV6p3dWic1qm1FLhip5beIyzZSt+ccTDYQQdPZA/t5H+k PZ7ZFBIUrXz/oEqwQwlEKlg8JQqg7hgtcL+xrIJ0BInLeSJG4lvvB551g59Thr7/ OsdxNVxKci775+K+GkdAz4xcULMuB+QE7t665Ri46EAS8ALos5UG6DGmhwCguD0v 1cxwy/KlKr+oi4sWM9caueED/RmjiSD3vmBZQt6PMisVe1AmkEf6cJoemduCSJxu 0eMz/LIeu+CqfpuJH2N/dZ3hRj9xMSHF4l71wKqV99zhm58kDGwG1u3yVzULPDqz 0yL+8nunlkoOUyn3zOnh3Zmz4POFVMZQ5oian3QkLllUwly5JCi5tWULxZ2vOkb0 zzjuA/4jigNxYV4NAyCl+wAbnyzk9/Iz8EHv4/0Ex8ytlcMtvBJKa9HjJxlyIl74 yOILHk3+GSAdM0b3ZmbavpoCpebinOMBhqEVBwCI4VUIAqf86gx+2dKBGxfKPnU4 Xxvqs/BOl/EbeJjyd4uieYndGRaWg+kYXqZ7SxrlFN24fohnd7QgSm9obiBEb25h Z2hlciA8am9obkB3ZWJtZXRhLmNvbT6IVgQTEQIAFgUCOcJnWgQLCgQDAxUDAgMW AgECF4AACgkQIt6tVu6+jd3SHwCgjssFktMXf8NjE9JBR+sJ2gDIsW8An0CFNdFd dU+DJYC6ogYP9AsVfM27uQENBDnCZ2MQBAD8E0qe1gBKjtoRmyiyORtwhOz/2XZE mqiZN2NouAUWRRZd4dHggFAA1jUsp2MVIZZQyY9ajNVy3Oaxj5kYz8LR5GItxxcD jC8RFXKM40ZfTJeR7fH6eJa689w+le71Tt4ALyN4xcjSWuksr8795AhHFjonDi8D rgGIq6GtWvi/KwADBgQAmeBbcjPzhqR2M8TdvEyNfVTQSSp/RNoTjNNWpHui8V0p kiQ49tbsqeMjXGToGgMugfmrX77JidXyuVjgYjT9xUdaaA25qKAR75M9izDliT7Y h5L+QZTAw0/5X9go7XK3WI3LYfFrp4TP0veXgSWxDqccqsRzWKW7IoXsliTCbVqI RgQYEQIABgUCOcJnYwAKCRAi3q1W7r6N3YIcAKCkJMTPLu6tOPnXPl2s3xmnSawy BACeOx83WlBhVScYWo+BUzntJ6ks4T0= =OkJU -END PGP PUBLIC KEY BLOCK- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
