Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Robert Cummings wrote: Don't forget nobody is being paid to handle bug reports, it's all on a volunteer basis and I'm quite certain they get oodles of real bogus bugs. Hi Robert it's a two-way thing - nobody is paying me to write any bug reports, I'm also volunteering my time and effort. Not just to PHP, but too quite a few projects. Fobbing people off like jani did me, is just not conducive to getting better bugreports nor to improving the project in general. HOWEVER - I've been studying the issue a bit more, and it appears that it IS indeed the responsibility of the application to call setlocale(LC_ALL, ); to become portable to all locales. Definitely not what I would have expected, but it's difficult to ignore the setlocale() man page: On startup of the main program, the portable C locale is selected as default. A program may be made portable to all locales by calling: setlocale(LC_ALL, ); /Per -- Per Jessen, Zürich (18.7°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per -- Per Jessen, Zürich (23.1°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per I don't mean to be rude, but I have never heard of or used these functions and never written a multi-lingual PHP site. I RTFM'd and found this: http://us.php.net/manual/en/function.setlocale.php Then I read the first sentence defining the second parameter, which states: If /locale/ is *NULL* or the empty string //, the locale names will be set from the values of environment variables with the same names as the above categories, or from LANG. Pretty straight-forward.
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Kyle Smith wrote: Per Jessen wrote: See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per I don't mean to be rude, but I have never heard of or used these functions and never written a multi-lingual PHP site. I RTFM'd and found this: http://us.php.net/manual/en/function.setlocale.php Then I read the first sentence defining the second parameter, which states: If /locale/ is *NULL* or the empty string //, the locale names will be set from the values of environment variables with the same names as the above categories, or from LANG. Pretty straight-forward. Did you bother reading the bug report? The PHP CLI ignores the locale setting from the environment such as set by setting LC_ALL. Your quoting from the manual does not change that. Now, if you can find a place in the manual that says the CLI will ignore whatever locale settings are set in the environment, we can talk again. /Per -- Per Jessen, Zürich (18.3°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: Kyle Smith wrote: Per Jessen wrote: See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per I don't mean to be rude, but I have never heard of or used these functions and never written a multi-lingual PHP site. I RTFM'd and found this: http://us.php.net/manual/en/function.setlocale.php Then I read the first sentence defining the second parameter, which states: If /locale/ is *NULL* or the empty string //, the locale names will be set from the values of environment variables with the same names as the above categories, or from LANG. Pretty straight-forward. Did you bother reading the bug report? The PHP CLI ignores the locale setting from the environment such as set by setting LC_ALL. Your quoting from the manual does not change that. Now, if you can find a place in the manual that says the CLI will ignore whatever locale settings are set in the environment, we can talk again. /Per I don't think your aggressive attitude to the situation is helping anyone here. The manual *explicitly* states that using setlocale(LC_xyz,'') will use the environment variable setting for that LC_xyz option. This *implies* that, by default, those environment variables are not used. Perhaps it should use the environment variables, instead? At any rate, it's not a bug, since someone(s) did it that way on purpose. You could file a feature request.
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Kyle Smith wrote:
Per Jessen wrote:
Kyle Smith wrote:
Per Jessen wrote:
See http://bugs.php.net/?id=48612
Thank you for taking the time to write to us, but this is not
a bug. And RTFM. (RTFM is my interpretation of the rest).
And that only took a little more than a month. Thanks very much.
Can anyone here tell me why the CLI behaviour reported is not a bug?
An explicit manual reference will do.
Btw, I brought it up here already:
http://marc.info/?l=php-generalm=124487699630514w=2
/Per
I don't mean to be rude, but I have never heard of or used these
functions and never written a multi-lingual PHP site. I RTFM'd and
found this:
http://us.php.net/manual/en/function.setlocale.php
Then I read the first sentence defining the second parameter, which
states: If /locale/ is *NULL* or the empty string //, the locale
names will be set from the values of environment variables with the
same names as the above categories, or from LANG.
Pretty straight-forward.
Did you bother reading the bug report? The PHP CLI ignores the locale
setting from the environment such as set by setting LC_ALL. Your
quoting from the manual does not change that. Now, if you can find a
place in the manual that says the CLI will ignore whatever locale
settings are set in the environment, we can talk again.
/Per
I don't think your aggressive attitude to the situation is helping
anyone here. The manual *explicitly* states that using
setlocale(LC_xyz,'') will use the environment variable setting for that
LC_xyz option. This *implies* that, by default, those environment
variables are not used.
Perhaps it should use the environment variables, instead? At any rate,
it's not a bug, since someone(s) did it that way on purpose. You
could file a feature request.
Sorry, just want to point out a difference, that I see, in the code
examples. Not trying to start anything here...
So, what does the example you provide have to do with the ops code
example in the bug report?
OPS example code from bug report
LC_ALL=de_DE.utf8 php -r print strftime('%B');
your example
setlocale(LC_xyz,'')
I don't see him using the above function in his example.
From what I can tell, the op is trying to set the locale /AT/ the cli,
not from within the script.
I guess my first debugging question would be:
Can you successfully set other LC_xyz categories, besides the LC_ALL, in
the same manor that your example shows?
If it works with the others (LC_COLLATE, LC_CTYPE, etc...) then I
/would/ call this a bug. Unless it has been explicitly stated somewhere
that the op has not found that This works with all but the LC_ALL
category.
Just my 2 bits worth.
Jim Lucas
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Kyle Smith wrote: I don't think your aggressive attitude to the situation is helping anyone here. The manual *explicitly* states that using setlocale(LC_xyz,'') will use the environment variable setting for that LC_xyz option. This *implies* that, by default, those environment variables are not used. Which is exactly the bug I reported. An application that deliberately ignores the locale setting passed from the environment is buggy unless it is clearly documented. Why should a developer be forced to be aware of the locale when it has already been done for him? That is just dim. Kyle, imagine this - assume the default locale for the PHP CLI is Greek. In everyone of your scripts you'd have to call setlocale() to get it to accept your otherwise default US locale. Where's the sense in that when your machine already has the correct locale? As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. /Per -- Per Jessen, Zürich (18.3°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Jim Lucas wrote:
Kyle Smith wrote:
Per Jessen wrote:
Kyle Smith wrote:
Per Jessen wrote:
See http://bugs.php.net/?id=48612
Thank you for taking the time to write to us, but this is not
a bug. And RTFM. (RTFM is my interpretation of the rest).
And that only took a little more than a month. Thanks very much.
Can anyone here tell me why the CLI behaviour reported is not a bug?
An explicit manual reference will do.
Btw, I brought it up here already:
http://marc.info/?l=php-generalm=124487699630514w=2
/Per
I don't mean to be rude, but I have never heard of or used these
functions and never written a multi-lingual PHP site. I RTFM'd and
found this:
http://us.php.net/manual/en/function.setlocale.php
Then I read the first sentence defining the second parameter, which
states: If /locale/ is *NULL* or the empty string //, the locale
names will be set from the values of environment variables with the
same names as the above categories, or from LANG.
Pretty straight-forward.
Did you bother reading the bug report? The PHP CLI ignores the locale
setting from the environment such as set by setting LC_ALL. Your
quoting from the manual does not change that. Now, if you can find a
place in the manual that says the CLI will ignore whatever locale
settings are set in the environment, we can talk again.
/Per
I don't think your aggressive attitude to the situation is helping
anyone here. The manual *explicitly* states that using
setlocale(LC_xyz,'') will use the environment variable setting for that
LC_xyz option. This *implies* that, by default, those environment
variables are not used.
Perhaps it should use the environment variables, instead? At any rate,
it's not a bug, since someone(s) did it that way on purpose. You
could file a feature request.
Sorry, just want to point out a difference, that I see, in the code
examples. Not trying to start anything here...
So, what does the example you provide have to do with the ops code
example in the bug report?
OPS example code from bug report
LC_ALL=de_DE.utf8 php -r print strftime('%B');
your example
setlocale(LC_xyz,'')
I don't see him using the above function in his example.
From what I can tell, the op is trying to set the locale /AT/ the cli,
not from within the script.
I guess my first debugging question would be:
Can you successfully set other LC_xyz categories, besides the LC_ALL, in
the same manor that your example shows?
If it works with the others (LC_COLLATE, LC_CTYPE, etc...) then I
/would/ call this a bug. Unless it has been explicitly stated somewhere
that the op has not found that This works with all but the LC_ALL
category.
Just my 2 bits worth.
Jim Lucas
I agree entirely, Jim. Would be a good test. My guess is that they all
behave the same way, based on how the setlocale() documentation reads.
- Kyle
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Jim Lucas wrote: From what I can tell, the op is trying to set the locale /AT/ the cli, not from within the script. Exactly Jim. A typical Linux installation in France/Germany/Greece/ Russia/whereever will have an appropriate environment (e.g. LC_ALL) set such that unix commands such as date and ls will display the information as appropriate for French, German, Greek and Russian. I guess my first debugging question would be: Can you successfully set other LC_xyz categories, besides the LC_ALL, in the same manor that your example shows? I guess it might be worth trying, but I think it's highly unlikely that any of the other settings will be accepted either. /Per -- Per Jessen, Zürich (18.3°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: Which is exactly the bug I reported. An application that deliberately ignores the locale setting passed from the environment is buggy unless it is clearly documented. Why should a developer be forced to be aware of the locale when it has already been done for him? That is just dim. In what sense is this a bug in PHP, though? If anything it is a bug in the documentation, but for Kyle at least, the existing documentation makes it clear that the pre-existing environment variable be ignored unless you call setlocale with a NULL or empty second argument. I had the same experience as Kyle, when I read the documentation at http://us.php.net/manual/en/function.setlocale.php -- and I thought to read that documentation because I first searched the bug database for LC_ALL (as requested at http://bugs.php.net/how-to-report.php ). Here's what I found: http://bugs.php.net/bug.php?id=48876 Which shed some light on the whole issue for me. After reading that bug report and the setlocale() manual page, it was clear to me that the PHP developers intended for PHP to initially ignore the environment variable LC_ALL. Your sense is that the developers made a bad design decision here, and perhaps you're right, but a bug is a mistake in the code that causes the software to do something other than what the developers intended. There's no bug here. As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. I thought the response on the bug was awfully polite under the circumstances. Again, from bugs.php.net's How to Report a Bug: 'Take special note of that word in bold above. The people who are going to help you with a bug you report are *volunteers*. Not only are you not paying them to help you, but nobody else is either. So, to paraphrase the immortal words of Bill and Ted, be excellent to them.' Have you read the classic How to Ask Questions the Smart Way? http://catb.org/~esr/faqs/smart-questions.html Ben -- Twitter: @bdunlap -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
On Fri, Jul 24, 2009 at 13:18, Per Jessenp...@computer.org wrote: As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. Per; We only reply like that when writing to you. Everyone else gets nice responses, but well, we just plain hate you, man. We took a vote and it was unanimous. Coincidentally, we also spoke with some of your relatives, and as it turns out, they want you out of the family as well. Sorry to be the bearer of bad news. Good luck in life. In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. That said, you're not the first (and certainly won't be the last) to feel miffed about it. The responses are not very diplomatic to those who have a good grasp of the English language, and the lack of inflection offered by printed words doesn't help. (P.S. - Stop crying. Your family didn't really say they want you out, but if they do, you can move to the US and have the shed in my back yard. Bring a blanket. ;-P) -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Check out our great hosting and dedicated server deals at http://twitter.com/pilotpig -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Ben Dunlap wrote: Per Jessen wrote: Which is exactly the bug I reported. An application that deliberately ignores the locale setting passed from the environment is buggy unless it is clearly documented. Why should a developer be forced to be aware of the locale when it has already been done for him? That is just dim. In what sense is this a bug in PHP, though? Well, I guess it is only a bug if one expects PHP to behave like a normal Unixy application. Mea culpa, perhaps. Have you read the classic How to Ask Questions the Smart Way? http://catb.org/~esr/faqs/smart-questions.html Ben -- Twitter: @bdunlap I can't help it, but I feel uncannily tempted to write you twit. /Per -- Per Jessen, Zürich (17.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Daniel Brown wrote: On Fri, Jul 24, 2009 at 13:18, Per Jessenp...@computer.org wrote: As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. Per; We only reply like that when writing to you. Everyone else gets nice responses, but well, we just plain hate you, man. We took a vote and it was unanimous. Coincidentally, we also spoke with some of your relatives, and as it turns out, they want you out of the family as well. Sorry to be the bearer of bad news. Good luck in life. I knew it. I did. There's a good reason I haven't lived in my home country for some 17 years . :-) In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. /Per -- Per Jessen, Zürich (17.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
On Fri, Jul 24, 2009 at 15:25, Per Jessenp...@computer.org wrote: Daniel Brown wrote: In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. At the risk of sounding redundant or dismissive myself (which I think you know me well enough by now to know is not the case), the best I could suggest would be to file a bug report pertaining to the wording of the responses. In all honesty, I don't see much being done in the way of changing that right away, but I could be wrong (which, in this case, would be welcome). By the way it's Friday night there. Why the heck are you still sitting in front of a computer?!? -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Check out our great hosting and dedicated server deals at http://twitter.com/pilotpig -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Daniel Brown wrote: On Fri, Jul 24, 2009 at 15:25, Per Jessenp...@computer.org wrote: Daniel Brown wrote: In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. At the risk of sounding redundant or dismissive myself (which I think you know me well enough by now to know is not the case), I do. (it's funny how you can get to know someone like that without ever having met them, but it's a fact). the best I could suggest would be to file a bug report pertaining to the wording of the responses. In all honesty, I don't see much being done in the way of changing that right away, but I could be wrong (which, in this case, would be welcome). I was actually being quite deliberate when I used the word braindead before - the automated click-of-a-button response may have its use, but one should always be careful with when to use it. Is there any way of filing a a bugreport on jani? Nah, perhaps I should file a doc-bug, but to be honest, I can't be bothered when the PHP project can't. It's a sad state of affairs. By the way it's Friday night there. Why the heck are you still sitting in front of a computer?!? It's 21:55 here and I'm really just a sad old git :-) Well, I've been busy keeping an eye on my 5 year old most of the day. His favourite playmate from next door was away today, which meant I didn't get to do much work until around 1830. (Amongst other things, I have a decidedly difficult mysql core dump I'm trying to capture). /Per, signing off for the night. -- Per Jessen, Zürich (17.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: Daniel Brown wrote: On Fri, Jul 24, 2009 at 15:25, Per Jessenp...@computer.org wrote: Daniel Brown wrote: In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. At the risk of sounding redundant or dismissive myself (which I think you know me well enough by now to know is not the case), I do. (it's funny how you can get to know someone like that without ever having met them, but it's a fact). the best I could suggest would be to file a bug report pertaining to the wording of the responses. In all honesty, I don't see much being done in the way of changing that right away, but I could be wrong (which, in this case, would be welcome). I was actually being quite deliberate when I used the word braindead before - the automated click-of-a-button response may have its use, but one should always be careful with when to use it. Is there any way of filing a a bugreport on jani? Nah, perhaps I should file a doc-bug, but to be honest, I can't be bothered when the PHP project can't. It's a sad state of affairs. By the way it's Friday night there. Why the heck are you still sitting in front of a computer?!? It's 21:55 here and I'm really just a sad old git :-) Well, I've been busy keeping an eye on my 5 year old most of the day. His favourite playmate from next door was away today, which meant I didn't get to do much work until around 1830. (Amongst other things, I have a decidedly difficult mysql core dump I'm trying to capture). I understand where you're coming from, and I've been on the same road before with PHP bug reports. And while I remember being really annoyed, especially when it turned out to actually be a bug, I have to say if you define your case clearly and state where either the documentation isn't clear enough, or the code works in an unexpected fashion, then they will usually give it the due consideration. Don't forget nobody is being paid to handle bug reports, it's all on a volunteer basis and I'm quite certain they get oodles of real bogus bugs. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
