[PHP-DEV] odbc setting boneheadedness? (odbc.defaultlrl)
Playing with db-based session handlers today against an ODBC database. Don't worry, it's not production, but it should work, and now it does... except that I had a hell of a time figuring out how to get all of the session data, when sessions get large, back from the db server. I found the odbc.defaultlrl setting pretty quickly, but my first try was to set it to 0 - which, I assumed, would mean no limit (like mssql.textsize). However, it appears that the comment really does _mean_ passthru there. So, is there any way to set it to a no limit value? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] After a few minutes the most aromatic and nice smelling Italian coffee will come out of the exhaustpipe. - Our stove-top espresso pot -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Odd array problems
With latest CVS (HEAD branch, checked out 10 or so minutes ago), the
following script:
?php
error_reporting(E_ALL);
$text = Before delim.br /\n--br /\nAfter delim;
$parts = preg_split('|(\n--\s*(br /)?\n)|', $text, 2, PREG_SPLIT_DELIM_CAPTURE);
$text = array_shift($parts);
if (count($parts)) {
echo 'pre /'; var_dump($parts);
$text .= $parts[0];
$text .= $parts[2];
}
?
Gives me this output:
array(3) {
[0]=
string(10)
--
[1]=
string(6)
[2]=
string(11) After delim
}
Notice: Undefined offset: 0 in /var/www/array.php on line 10
Notice: Undefined offset: 2 in /var/www/array.php on line 11
But the var_dump() clearly shows that there _are_ elements 0 and 2 in
the array. What am I missing, or is something still off with the array
code?
-chuck
--
hello, I'm a giant cheese, and I'm here to give you a therapeutic massage
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Odd array problems
Quoting Brad LaFountain [EMAIL PROTECTED]: Should be fixed. I swear there better not be anything else wrong with that code chage :) I know alot more how the engine handles arrays now :) Confirming that things seem to work as expected now. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] After a few minutes the most aromatic and nice smelling Italian coffee will come out of the exhaustpipe. - Our stove-top espresso pot -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
Quoting Yasuo Ohgaki [EMAIL PROTECTED]: It just does not make sense to store original(case sensitive) names while langage ignores case. It's also confusing, lead to case sensitivity BC problem anyway just like with case sensitive function/names. It's more confusing, IMHO, to punish people who are otherwise consistent by making them check for a different classname than they are using (the lowercase version). That is _very_ unintuitive. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] What was and what may be, lie, like children whose faces we cannot see, in the arms of silence. All we ever have is here, now. - Ursula K. Le Guin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cvs.php.net: CHORA problem
Quoting Yasuo Ohgaki [EMAIL PROTECTED]: I guess your browser does not support gzip encoding. Well, you guess wrong. Try to avoid jumping to conclusions which you have no basis for, except that it makes things someone else's fault. I use Mozilla 0.9.6+. Mozilla (and Netscape 4, too) have inconsistencies in their gzip support. Netscape 4, at least, couldn't print encoded pages - the data sent to the printer isn't decompressed - and it looks like both of them don't decompress data when it is downloaded. Of course, you can ungzip it yourself, and you could also argue that the browser doesn't know it isn't just a gzip file - except that the Content-Type is correct; gzip is just in the Content-Encoding. So Mozilla is broken. You should probably file a bug report. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] What was and what may be, lie, like children whose faces we cannot see, in the arms of silence. All we ever have is here, now. - Ursula K. Le Guin -- 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] cvs.php.net: CHORA problem
Quoting Chuck Hagenbuch [EMAIL PROTECTED]: Quoting Yasuo Ohgaki [EMAIL PROTECTED]: I guess your browser does not support gzip encoding. Well, you guess wrong. Try to avoid jumping to conclusions which you have no basis for, except that it makes things someone else's fault. I meant to provide slightly more backup for this - try using wget. It doesn't support gzip encoding, and it downloads a text file just fine. And IE (6 at least, probably 4+) works as well. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] What was and what may be, lie, like children whose faces we cannot see, in the arms of silence. All we ever have is here, now. - Ursula K. Le Guin -- 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] cvs.php.net: CHORA problem
Quoting Yasuo Ohgaki [EMAIL PROTECTED]: CHORA's download feature is broken somewhat... If I download source file, it is gzipped! (it can be other format also... I guess) Works fine for me. What client are you using? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] What was and what may be, lie, like children whose faces we cannot see, in the arms of silence. All we ever have is here, now. - Ursula K. Le Guin -- 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] ?php= ? sytanx again
Quoting Edin Kadribasic [EMAIL PROTECTED]:
Combine that with incompatibility of PHP's short open tag with XML, and the
reason for having ?php= becomes clearer.
As Rasmus is probably tired of pointing out, this isn't much of an argument.
This:
if ($i 4) {
...
is incompatible with XML (it'd have to be if ($i lt; 4) ...)
I find it unfortunate that there's a feature available with short tags on that
isn't available with them off, because that means it's a feature that you can't
use if you want to write code that'll work with anyone's php installation. But
that's about it - I end up on the fence.
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
What was and what may be, lie, like children whose faces we cannot see, in the
arms of silence. All we ever have is here, now. - Ursula K. Le Guin
--
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: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
Quoting Andrei Zmievski [EMAIL PROTECTED]: sigh I step away from the computer for the weekend, and such an interesting discussion ensues. For the record, I'd vote for either unifying classes and namespaces (I like that approach) As do I... Andi, Zeev - are there technical problems with this? We already have static class methods; having static class variables and static class-specific constants seems like a logical extension of this to me, and it gives you a class-is-a-namespace concept which seems very workable to me... -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] What was and what may be lie, like children whose faces we cannot see, in the arms of silence. All we ever have is here, now. - Ursula K. Le Guin -- 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: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
Quoting Harald Radi [EMAIL PROTECTED]: is there a reason why a namespace should contain anything other than classes ? we have static functions and static members in classes, no need for them in namespaces too. We don't have static members. And we need namespaces for constants, also. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] RE: [Zend Engine 2] Re: [PHP-DEV] RE: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
Quoting Harald Radi [EMAIL PROTECTED]:
And we need namespaces for
constants, also.
why ?
class Foo {
final $BAR = blah;
}
I'm sorry, I haven't been following all of this - is 'final' a keyword that
will be available (and enforced) in ze2?
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity
Quoting Zeev Suraski [EMAIL PROTECTED]: :: is taken, but why not do it the C++ way? It also uses :: for both classes and namespaces. +1 on that. -chuck -- Because of your melodic nature, the moonlight never misses an appointment. - fortune cookie -- 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] Woah
Quoting Wez Furlong [EMAIL PROTECTED]: 2. Create a php config directive that allows you to do the same thing -1. Config directives are a huge headache for people who distribute code (and for projects like PEAR). Let's not encourage adding more of them, when there are much better solutions... (yes, Wez, I know this wasn't your top choice) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Joey Smith [EMAIL PROTECTED]: I would rather see something to the effect of use strict; (as in perl) that can be defined (per site/directory/namespace/SOMETHING...) to mean use gettext on all calls to print than to see _() stay. That would not provide the same functionality - you don't always want to print the internationalized string. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] delete (was: Re: [PHP-DEV] Woah)
Quoting Zeev Suraski [EMAIL PROTECTED]: Oh yummy, we have delete()?! Zeev: in this case, you can relax. From http://www.php.net/manual/en/function.delete.php: This is a dummy manual entry to satisfy those people who are looking for unlink () or unset() in the wrong place. It's not actually in the namespace in any capacity whatsoever. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Steve Langasek [EMAIL PROTECTED]:
So I'm all for removing _() from the gettext extension... but I think the
people who are so eager for this have a responsibility to make sure PHP has a
good option for user-aliasing of functions in place before it goes away.
I think if something like this had been suggested in the first place, instead
of the all-out annihilate _() warfare that took place (and yes, I am guilty of
responding in kind), we might have had a much shorter discussion. Something to
consider for the future. :)
I would be happy with this kind of solution (removing _() after there is a user-
space alias_function() call which can create a new name for a PHP function). I
would be even happier if calling alias_function('gettext', '_') would simply do
nothing if _() already pointed to gettext(), but I won't quibble about the
function_exists() check.
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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] Woah
Quoting Cristopher Daniluk [EMAIL PROTECTED]: Agreed, but is the speed loss really worth crying about? Obviously not to you, but I'm pretty sure you came down in the category of people who'd never used gettext. It is negligible calling a userspace function versus an internal compared to the greater work that the typical PHP script does. What authority do you have to make this statement? Rasmus posted numbers. Where are yours? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Rasmus Lerdorf [EMAIL PROTECTED]: This doesn't mean I agree with the magic _() function, but until we have some sort of efficient run-time function aliasing mechanism like they do in Python, removing _() and telling people to create a user-space function that calls gettext() is not going to make the gettext using people very happy with us. The way this was solved in Python is that they have a gettext.install method which creates the _() function in the builtin namespace. The function is only present once this install method is called on the gettext object. See http://www.python.org/doc/2.1/lib/node187.html Having some elegant solution like either of the ones outlined above would go a long way towards making yanking _() out of the gettext module seem reasonable to me. Zeev: were it being added now, no, I wouldn't argue for it. My argument is based on it having been there for years and being in heavy use in some people's code. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: Why the heck do we have: PHP_FALIAS(_, gettext,NULL) in ext/gettext/gettext.c It's a standard alias in the c library as well: http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC15 It makes code look a lot less convoluted, when you just wrap strings in _() instead of having gettext() all over the place. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: So I heard, but it's extremely un-PHPish and obscure. It also makes gettext useable. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: It also makes gettext useable. I don't buy that. 'gettext' is hardly the only token that's used repeatedly throughout PHP, and we never made any exceptions anywhere else. It's the kind of thing that gets used a lot in HTML, where otherwise there wouldn't be a function call at _all_ - just static text. Replacing gettext() with _() in this case actually does improve readability, in my opinion. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php That's unfortunate. IMHO, it should be phased out. Exceptions in php extensions have been made before where the extension mirrors the c library exactly, in order to not confuse people familiar with the library. This is another one of those cases - people familiar with gettext will be very confused if _() doesn't work the way they expect it to. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: There's no mention of _() in that page, by the way. Only gettext(). You may use an underscore character as an alias to this function. It could be clearer, certainly. But it's there. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Joey Smith [EMAIL PROTECTED]: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. I know that backwards compatibility is a pain in the ass, but you might want to consider that this has been around ever since the gettext extension was introduced, before launching the next crusade. Just out of the curiosity, have any of the people jumping on the bandwagon to bash this ever actually _used_ gettext at any kind of scale? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Joey Smith [EMAIL PROTECTED]: No, I haven't, but let me get this straight: You're saying that if something is a bad idea, that the more often it is used, the less bad [1] it becomes? Uh, no. I was just pointing out that it's been around for a long time, and is used in a lot of code. Like Ken said, breaking it - many years later - for language elegance seems rather unproductive. If it were up for inclusion now, it'd be a completely different story. The _reason_ backwards compability is a pain in the ass is that sometimes you have to put up with things like this because they get entrenched. Also, I asked if the people bashing it had used gettext just because I'd imagine that people who had used a feature would have a better idea on whether or not it is obscure or useful. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] Woah
Quoting Cristopher Daniluk [EMAIL PROTECTED]: But I think the point is this function has no business in the core language. It's not in the core language. It's in the gettext extension. -chuck -- I have pointy little boobs! - Jason -- 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] MFH'ing PEAR changes
Quoting Stig S. Bakken [EMAIL PROTECTED]: Any objections against me MHF'ing some non-critical stuff in php4/pear? It's so long between each PHP release now that the PEAR stuff that comes with PHP is usually outdated by the day of the release. :-P For the record, I think we should sync up pretty much everything before release... -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] API Thoughts?
Alright. I think I've stated this before, but, just so everyone knows: I'm
gonna kick and scream whenever I think something is being done for expediency
and it's the wrong thing to do from a design/engineering perspective. You're
probably all gonna hate me, but someone has to do it.
Quoting Sterling Hughes [EMAIL PROTECTED]:
The above are imho pretty ugly, and this is meant as more of a language
level feature, I'm thinking of using PEAR as more of a method of
distribution than a mindset.
They are only ugly because we don't have namespaces in PHP. If we had
namespaces, then your code example (which I'll comment on below) would be fine.
But as is, the way you are organizing the code causes namespace pollution. This
isn't something that we can stop end-user developers from doing, but if we
don't strictly adhere to namespace standards in the code in PEAR, _no one_ will
do it, and we will have a mess on our hands.
Some standards are only worth having if you enforce them. I think class naming
is one of them.
The current way I have it organized is as follows:
php4/pear/ADT.php
php4/pear/ADT/LList.php
php4/pear/ADT/Stack.php
php4/pear/ADT/Queue.php
php4/pear/ADT/AVLtree.php
php4/pear/ADT/BTree.php
php4/pear/ADT/RBTree.php
php4/pear/ADT/Heap.php
php4/pear/ADT/Set.php
If you want the tree classes to share the same API - or even a subset of it,
they _really_ should be subclasses of an ADT_Tree class.
then you could do something like:
?php
require_once('ADT/Queue.php');
$sounds = new Queue;
[snip]
If you make that $sounds = new ADT_Queue(); ... then I'm happy.
(pet peeve: require_once and friends are statements. You don't need the
parentheses.)
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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] ext/gettext adding *ngettext functions
Quoting Walter Franzini [EMAIL PROTECTED]: I have added to ext/gettext the wrapper needed to support *ngettext functions, you can find the patch below. Committed, thanks! -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] API Thoughts?
Quoting Sterling Hughes [EMAIL PROTECTED]:
Jep -- I'm writing PEAR OO wrappers for every ADT that I implement
in a functional manner. I'm think for the OO wrappers, seperate
class names wouldn't be horrible, something like:
$tree = new AVLTree;
Please stick to the naming conventions, which would make this:
$tree = new ADT_Tree_AVL();
... or something similar. Also, you could easily have a factory method:
$tree = ADT::factory('tree_avl');
or:
$tree = ADT_Tree::factory('avl');
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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] Re: [PATCH] ext/imap (imap_search)
Quoting Rob Siemborski [EMAIL PROTECTED]: The addition of a tail pointer to the list fixes this problem. I also made the free function non-recursive, which is somthing that could probabally be applied to most of the list-freeing functions in php_imap.c Cool. It's committed. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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
Quoting Cynic [EMAIL PROTECTED]: I have submitted a patch to the chora list. you'll be able to get the latest revision in HEAD with e. g. http://cvs.php.net/co.php/php4/NEWS That link will now work. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] IMAP setacl command...
Quoting Brian Masney [EMAIL PROTECTED]: I have enclosed a patch that adds support for the IMAP setacl command that is found in the Cyrus IMAP package (and probably others). If anyone has any problems with this, please let me know. Please attach the patch in plain text format or post a link where we can download it - the list strips non text attachments and attachments over a certain size. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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 techniques
Quoting Rasmus Lerdorf [EMAIL PROTECTED]: Huh? I use this all the time in my apps. There is absolutely nothing wrong with having both GET and POST method variables at the same time. Disallowing this would break almost every app I have ever written. Well, it works fine with Apache, and probably some other servers, but it doesn't work with Netscape Enterprise Server - it's not officially part of the spec, afaik. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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 techniques
Quoting Rasmus Lerdorf [EMAIL PROTECTED]: As long as it works with all browsers, which as far as I can tell it does, then it doesn't really concern me that some servers don't support it. Apache will definitely always support this. Yup - I haven't found a browser that has problems with it. And it certainly is useful. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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 installed
Quoting Anil Madhavapeddy [EMAIL PROTECTED]: Fix the mime_drivers.php to point to tar correctly. http://chora.php.net/co.php/phpweb/Mirrors-htdig.tgz?sa=1r=1.4 Got it. and GNU Enscript in there can pretty-print C files as well, if you want. That's already set up. :) And if you put an entry in for cvsusers in the cvsroots.php config file, it will automatically expand committer's full names and email addresses. Got that up, also. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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] imap_open -- stream error
Quoting saurav bhowmik [EMAIL PROTECTED]:
I just try an example here, using imap_open connect to
yahoo mail.
This list is for the development of PHP, not development _in_ PHP. However:
?$mbox = imap_open ({pop.mail.yahoo.com:110},
user_mail_id, user_password);
Take a look at the second example given at
http://www.php.net/manual/en/function.imap-open.php. You're missing the /pop3
in the server string.
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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-QA] RE: [PHP-DEV] Re: [PHP-QA] Modifications to Windows Readme file
Quoting Liz [EMAIL PROTECTED]: the IMAP, POP and NNTP functions section.. it only contains imap functions. Im sure this is confusing to people. It's the names of the functions that are wrong, not the name of the section. Read the documentation for imap_open() - it'll talk to pop3 and nntp servers just fine, and almost all of the functions work with all three. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] When you can't even start, it's time to stop - Jason -- 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
Quoting Zeev Suraski [EMAIL PROTECTED]: The other, is a more fundamental change, and it is to change PHP to be case dependant. PHP 4.0 follows the standard set by PHP/FI 2.0 (or earlier), and maintains case sensitivity for variable names, but not function names or class names. IMHO, there's very little reason for this inconsistency, and PHP would have been better off with full case sensitivity across class names, function names and variable names. It would also improve performance fairly significantly. +1 I've always treated php as case sensitive just because I was confused as to where it was and where it wasn't. Having it actually be that way would be great. -chuck -- It takes 170 decibels to rupture the human eardrum. Less, if Celine Dion is singing. -- 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
Quoting Colin Viebrock [EMAIL PROTECTED]: One problem with case sensitivity (perhaps) is that it may make some scripts non-portable. That's a problem with it being an option, yes. I'd vote for just making php case sensitive, period. -chuck -- must... find... acorns... *thud* -- 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] __FILE__ constant
It was a change in Zend (I'm nearly positive) that broke the __FILE__ constant. I've heard one person verify this and one person say it works for them; can people running latest cvs (and latest cvs of Zend, as well) say if it works for them or not? I tried to poke around in Zend a bit to see what might have done it, but it's a pain to look through histories without a cvsweb interface, and I didn't see anything obvious. It's probably something small, but it's severely breaking some of my code. Could a Zend guru take a look at it? Thanks, -chuck -- ...and remember: elmo is _not_ an insertion toy. -- 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] mailparse extension
Quoting Wez Furlong [EMAIL PROTECTED]: I would like to put my mailparse (As seen on zend.com weekly summary) extension into CVS; shall I just check it into php4/ext? I'd certainly be interested in it. Are there any external library dependancies? -chuck -- Hockey means never having to say you're sorry. -- 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] Imap SSL support (Bug #10330)
Quoting J. Jones [EMAIL PROTECTED]: The imap module fails with the following (perhaps only when building against imap-2000*): php_imap.c: In function `php_minit_imap': php_imap.c:450: `auth_ssl' undeclared (first use in this function) php_imap.c:450: (Each undeclared identifier is reported only once php_imap.c:450: for each function it appears in.) This code branch should only be triggered if HAVE_IMAP_SSL is defined, which should only happen if you configure php --with-imap-ssl. If you're doing so, it's assumed that you've built c-client with SSL support. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] You will receive an urgent transmission from the Martian government informing you that Mars does not, in fact, need women, so please stop sending them. -- 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] request
Quoting Andrei Zmievski [EMAIL PROTECTED]: You could have two classes both defining an innocent method toString(), for example, and with your suggestion, inheriting from those classes would cause a hard error? Why would "first encountered" definition change? If anything that affected how classes were ordered changed, if the classes were renamed, if the class definitions changed... -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Taurus: You will receive an urgent transmission from the Martian government informing you that Mars does not, in fact, need women, so please stop sending them. -- 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] Suggestion for in_array
Quoting Thomas Deliduka [EMAIL PROTECTED]: Perhaps having in_array return the index for the element that contains the needle. That would be very useful. No, that would break the semantics of the function, because the index could be 0, which evaluates to false in boolean expressions. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Taurus: You will receive an urgent transmission from the Martian government informing you that Mars does not, in fact, need women, so please stop sending them. -- 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] request
Quoting Andrei Zmievski [EMAIL PROTECTED]: Alternatively, we could do the Python way: the base classes are searched in depth-first order, and if the base classes define the same symbol, the first encountered definition is used. This could result in really confusing and unpredictable behavior if "the first encountered definition" changed under any circumstances. I'd vote for making any name conflicts an error. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Taurus: You will receive an urgent transmission from the Martian government informing you that Mars does not, in fact, need women, so please stop sending them. -- 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] request
Quoting Stanislav Malyshev [EMAIL PROTECTED]: I don't know why very these ones are the "biggest", but it's possible to "resolve" them, taking into account that every resolution would be necessarily imperfect, since the situation itself is no good. Okay, I've gone and refreshed my memory a bit. There's a pretty good article on the topic here: http://www.elj.com/eiffel/feature/inheritance/mi/review/ There can be a number of strategies, e.g.: 1. Requiring exact qualification on each call 2. Choosing one of them (fits for variables, worse for methods) 3. Declaring the situation to be an error etc., etc. Going with my own instincts and the opinions of the above article, 1 or 3 would be acceptable solutions. And 2 doesn't _always_ work for variables, in the case that you're encapsulating two objects with distinct states. That said, I'm still against it because of the complexity that it adds and the misuse that it encourages. I'd rather see interfaces (and namespaces! - though that's not a solution for the same problem). -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Taurus: You will receive an urgent transmission from the Martian government informing you that Mars does not, in fact, need women, so please stop sending them. -- 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] Re: [PEAR-DEV] Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
Quoting Derick Rethans [EMAIL PROTECTED]: I would go for optionally on, I really dont want to build both the apache module (p.e.) AND the CGi at the same time. For QA testing this is fine, but not for production servers. But if the PEAR installer is going to depend on the cgi version of php, we're going to need it installed on machines by default. Making people build php twice in order to use PEAR is going to kill user acceptance. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- 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] Request for new feature: $HTTP_SESSION_VARS when register_globals = on
Quoting Sascha Schumann [EMAIL PROTECTED]: - but that does make it really messy to write code that works with either setting. Yes. Feel free to propose a solution which solves your problem and which is compatible to existing scripts. What about adding session_set_var (and session_get_var, for symmetry) functions to set and access session variables regardless of scope? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- 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: ; arg seperator
Quoting Hartmut Holzgraefe [EMAIL PROTECTED]: arg_separator.output should default to 'nbsp;'. nbsp; ??? i guess it will break lots ;) maybe we should amp; instead? Wow. Yeah, I'm really tired this morning. amp; is what I meant, of course... Thanks, Hartmut. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- 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: ; arg seperator
Quoting Joey Smith [EMAIL PROTECTED]: I've never bought into this argument, because these companies can include a "config.php", or something like that, which uses ini_set() to set up the INI file however they need it... But commercial companies aside, the plethora of configuration options (like magic_quotes_gpc) can and does make life harder for people writing code libraries (like PEAR) that are meant to be dropped in anywhere, or for people trying to write applications that have minimal setup required, or that people can install on hosts where they don't have access to the php.ini parameters. It's certainly something to keep in mind. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- 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] POP3 functions
Quoting Eric [EMAIL PROTECTED]: Is it possible to submit functions for addition to php? I have some functions which I've added to my local copy of: ext/imap/php_imap.c and prototypes in ext/imap/php_imap.h Yup, this is where to send them... -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- 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] frontbase always on in configure?
With current cvs, I can't seem to run configure without it trying to find frontbase - I've tried not saying anything at all about frontbase, saying -- without-fbsql, and --disable-fbsql, and all 3 ways, I get: checking for FrontBase SQL92 (fbsql) support... yes configure: error: Cannot find FrontBase in well know installation directories ... from configure. Any ideas? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] "Live, from Washington, where the doctors were telling us what they did, and did not, do with Vice President Cheney." -Dan Rather -- 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] IMAP and the mail_parameters
Quoting Dan Kalowsky [EMAIL PROTECTED]: The implementation of a universal function could potentially be extremely useful for controlling imap services. But some advise on this would be welcome... or if there currently is such an ability that would be great to hear! So.. any preference? The other problem with universal is that what you get back from mail_parameters depends on what you're doing with it. For instance, if I remember correctly, calling mail_parameters to ask for NAMESPACE gives you back a funky data structure that c-client uses to define namespaces, while most things give you just an int return value. So maybe we should have specialized functions, though universal would be great if we could manage it. The NAMESPACE example isn't incidental; we really should have access to that from php-space. I just haven't gotten around to implementing it yet. So if you want a hand with any of this, feel free to let me know. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -A NASA scientist -- 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] Re: [PHP-PEAR] something I noticed re:licenses.
Quoting Joao Prado Maia [EMAIL PROTECTED]: Agreed. Especially since every single one mentions binarycloud. I thought I was the only one thinking this way. Thanks Nathan :) It's ridiculous to beat on Alex when 4 or 5 people seem to have been taking the same stance from a PHPLIB viewpoint. Alex has put a lot of work into building binaryclound and thinks everyone should use it 'cause it's so nifty. The PHPLIB folks claim a large installed base and that PEAR should accept the phplib code as it is so as not to create compatibility problems. Everyone has their own ego and their own horse to ride. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Entropy. It's what's for dinner. -- 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] Re: [PHP-PEAR] Merging PHPLIB into PEAR
Quoting Paul Meagher [EMAIL PROTECTED]: Personally, I don't see the big deal if someone wants to call a method like this $this-empy_cart versus $this-emptyCart. The point is consistency. If every class in PEAR uses the same method naming conventions, then it will be easier for developers to develop with PEAR libraries because it will be easier for them to remember what things are called. It's like coding in Java and PHP and switching back and forth: you can certainly train your mind to do it, but once in a while you'll find yourself putting $ in front of java variables, or having to stop and think about something that's different between the two. And there's no reason for us not to just pick one - which I thought we had done - and stick with it. We lose nothing, and gain consistency. In the case of PHPLIB it is probably creating alot of unnecessary work, headache and backward incompatabilities to try to convert to the PEAR standard. If the DB layer is changing, then there are going to be backwards compatibility problems anyway, and they might end up being more subtle and hard to find. Why not provide scripts to convert users' code to use the new names? Why assume that the API is going to be the same, anyway? If we put our standards and conventions up for discussion every time someone decides to contribute a decent chunk of code to PEAR, we'll never get anywhere. I personally don't want to be spending my time on this same discussion a year from now, or even a month. But what will be, will be. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Entropy. It's what's for dinner. -- 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] Timezone offset differences
Quoting Jim Winstead [EMAIL PROTECTED]:
i didn't check how date('Z') is defined (do you add it to local time to get
UTC or subtract it?) but it may be that systems where struct tm has a
tm_gmtoff member and systems that use the timezone global may
define it different ways.
they should be made consistent, and the date() documentation updated to
tell exactly which way we've made it consistent. :)
For the record, I reported a similar problem on win32 a while ago, though it
was with date('r') (rfc822 date), but showed the same thing - wrong sign for
the timezone offset.
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Entropy. It's what's for dinner.
--
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]
