This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 13:59:05 von Per Jessen
See http://bugs.php.net/?id=3D48612
"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? A=
n
explicit manual reference will do.=20
Btw, I brought it up here already:
http://marc.info/?l=3Dphp-general&m=3D124487699630514&w=3D2
/Per
--=20
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: This is the kind of [expletives deleted] answer that iscertain to prevent bugs being reported.
am 24.07.2009 16:19:01 von kyle.smith
--------------090706080507000506090108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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-general&m=124487699630514&w=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.
--------------090706080507000506090108--
Re: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 17:55:16 von Per Jessen
Kyle Smith wrote:
> Per Jessen wrote:
>> See http://bugs.php.net/?id=3D48612
>>
>> "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?=
=20
>> An explicit manual reference will do.
>>
>> Btw, I brought it up here already:
>> http://marc.info/?l=3Dphp-general&m=3D124487699630514&w=3D2
>>
>>
>> /Per
>>
>> =20
> 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:
>=20
> http://us.php.net/manual/en/function.setlocale.php
>=20
> 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".
>=20
> 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.=20
/Per
--=20
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: This is the kind of [expletives deleted] answer that iscertain to prevent bugs being reported.
am 24.07.2009 18:15:20 von kyle.smith
--------------080408040309080201080002
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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-general&m=124487699630514&w=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.
--------------080408040309080201080002--
Re: This is the kind of [expletives deleted] answer that iscertain to prevent bugs being reported.
am 24.07.2009 19:12:17 von List Manager
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-general&m=124487699630514&w=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: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 19:18:14 von Per Jessen
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.=
=20
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 reportin=
g
the bug, and
2) the behaviour is at best undocumented,
well, yes, it p...... me off. It's just not professional and not at al=
l
conducive to getting any more bugs reported.=20
/Per
--=20
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: This is the kind of [expletives deleted] answer that iscertain to prevent bugs being reported.
am 24.07.2009 19:24:00 von kyle.smith
--------------040300050402080600020008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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-general&m=124487699630514&w=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
--------------040300050402080600020008--
Re: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 19:26:21 von Per Jessen
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.=20
> I guess my first debugging question would be:
>=20
> 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.=20
/Per
--=20
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: This is the kind of [expletives deleted] answer that iscertain to prevent bugs being reported.
am 24.07.2009 19:43:16 von Ben Dunlap
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: This is the kind of [expletives deleted] answer that is
am 24.07.2009 19:52:13 von Daniel Brown
On Fri, Jul 24, 2009 at 13:18, Per Jessen 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. =A0It's just not professional and not at al=
l
> 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)
--=20
daniel.brown@parasane.net || danbrown@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: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 21:24:17 von Per Jessen
Ben Dunlap wrote:
> Per Jessen wrote:
>=20
>> 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.
>=20
> In what sense is this a bug in PHP, though?=20
Well, I guess it is only a bug if one expects PHP to behave like a
normal Unixy application. Mea culpa, perhaps.=20
> Have you read the classic "How to Ask Questions the Smart Way"?
> http://catb.org/~esr/faqs/smart-questions.html
>=20
> Ben
> --
> Twitter: @bdunlap
I can't help it, but I feel uncannily tempted to write "you twit".=20
/Per
--=20
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: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 21:25:51 von Per Jessen
Daniel Brown wrote:
> On Fri, Jul 24, 2009 at 13:18, Per Jessen 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 n=
ot at
>> all conducive to getting any more bugs reported.
>=20
> Per;
>=20
> 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 o=
f
> 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.=20
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.=20
/Per
--=20
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: This is the kind of [expletives deleted] answer that is
am 24.07.2009 21:31:31 von Daniel Brown
On Fri, Jul 24, 2009 at 15:25, Per Jessen wrote:
> Daniel Brown wrote:
>> =A0 =A0 In reality, those are canned responses. =A0Jani 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. =A0To 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. =A0So 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?!?
--=20
daniel.brown@parasane.net || danbrown@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: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 21:56:11 von Per Jessen
Daniel Brown wrote:
> On Fri, Jul 24, 2009 at 15:25, Per Jessen 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 b=
y
>> 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.
>=20
> 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),=20
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.=20
> 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 :-)=20
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.
--=20
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: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 24.07.2009 22:11:52 von Robert Cummings
Per Jessen wrote:
> Daniel Brown wrote:
>
>> On Fri, Jul 24, 2009 at 15:25, Per Jessen 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
Re: This is the kind of [expletives deleted] answer that is certainto prevent bugs being reported.
am 24.07.2009 23:00:16 von Lupus Michaelis
Per Jessen wrote:
> See http://bugs.php.net/?id=48612
I don't understand too the answer. For me it is obvious it is a bug
because it breaks the system locale behaviour.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Seeking for a position
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: This is the kind of [expletives deleted] answer that iscertainto prevent bugs being reported.
am 24.07.2009 23:07:54 von Greg Beaver
Robert Cummings wrote:
> 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.
Hi,
I suggest anyone with a casual interest in understanding where php
developers who respond to bugs are coming from, just read the reports
and comments as they come through the php-bugs list (php.bugs on the
news server).
Watch how many obvious bugs with issues (i.e. bogus bugs) come through,
and note what the rate of mis-judgements by the devs responding to bugs
is, it is very very low, but not 0%.
You'll also notice Jani responds to almost everything, either assigning
it to someone, or closing the ones he sees as obvious for one reason or
another.
You'll also notice that both he and users can be far more acidic than
the canned responses, and yes - if you have a suggestion for improving a
canned response, it will be taken seriously.
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: This is the kind of [expletives deleted] answer that is certain to prevent bugs being report
am 25.07.2009 12:27:05 von Per Jessen
Lupus Michaelis wrote:
> Per Jessen wrote:
>> See http://bugs.php.net/?id=3D48612
>=20
> I don't understand too the answer. For me it is obvious it is a bu=
g
> because it breaks the system locale behaviour.
>=20
Thanks, I'm glad I'm not alone in thinking this.=20
/Per
--=20
Per Jessen, Zürich (18.1°C)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: This is the kind of [expletives deleted] answer that iscertain to prevent bugs being reporte
am 25.07.2009 15:40:58 von Tom Worster
On 7/25/09 6:27 AM, "Per Jessen" wrote:
> Lupus Michaelis wrote:
>
>> Per Jessen wrote:
>>> See http://bugs.php.net/?id=48612
>>
>> I don't understand too the answer. For me it is obvious it is a bug
>> because it breaks the system locale behaviour.
>>
>
> Thanks, I'm glad I'm not alone in thinking this.
to many people, a documented bug is like a false truth: it simply cannot
exist. the premise is that a bug, by definition, is not documented. if it's
documented then it's a feature and a feature is never also a bug.
i'd wager that one devotee of this doctrine would be the bug checker who
shot off that superior, sneering insult in the disposition of your bug
report.
if that response was a standard text built into the bug management system
then it suggests the doctrine pervades the culture on the team.
in my view, the premise doesn't hold up very well. we can all think of bugs
that could not reasonably be be debugged by documenting them. hence there is
a zone in the spectrum between "obvious bug" and "obvious non-bug". saying
"go away and rtfm" when discussing behaviors in this zone is not respectful.
failure of a cli program to behave idiomatically under unix (or that finnish
os that shares so many of the idioms) is arguably a bug -- it's in that
zone. the response you got, per, was a cheap brush-off.
btw: i think setlocale() is not the right place to document the "feature"
that php cli ignores standard environment variables.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: This is the kind of [expletives deleted] answer that
am 26.07.2009 06:23:41 von Paul M Foster
On Fri, Jul 24, 2009 at 04:07:54PM -0500, Greg Beaver wrote:
> Robert Cummings wrote:
>
> > 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.
>
> Hi,
>
> I suggest anyone with a casual interest in understanding where php
> developers who respond to bugs are coming from, just read the reports
> and comments as they come through the php-bugs list (php.bugs on the
> news server).
>
> Watch how many obvious bugs with issues (i.e. bogus bugs) come through,
> and note what the rate of mis-judgements by the devs responding to bugs
> is, it is very very low, but not 0%.
>
> You'll also notice Jani responds to almost everything, either assigning
> it to someone, or closing the ones he sees as obvious for one reason or
> another.
>
> You'll also notice that both he and users can be far more acidic than
> the canned responses, and yes - if you have a suggestion for improving a
> canned response, it will be taken seriously.
I have to agree with the canned response. You've got volunteers working
to produce one of the most-used languages on the web. The canned
response saves time and gets the point across-- it's a feature, not a
bug (from the viewpoint of the developers). Cut them some slack.
On the other hand, I disagree with PHPs behavior with respect to the
CLI. I can see that behavior in a web environment, but not with the CLI.
Per's right that in a *nix environment, the default behavior is to honor
the environment locale settings. Having to set the locale within a CLI
is silly and counterintuitive with respect to *nix applications. I can't
speak for Windows here.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
am 26.07.2009 12:24:02 von Per Jessen
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.=20
HOWEVER - I've been studying the issue a bit more, and it appears that
it IS indeed the responsibility of the application to call=20
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 a=
s
> default. A program may be made portable to all locales by calling:
>
> setlocale(LC_ALL, "");
/Per
--=20
Per Jessen, Zürich (18.7°C)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: open source forum
am 26.07.2009 14:42:03 von David Robley
mrfroasty wrote:
> Hello,
>
> I need some advice in picking a PHP forum for a group of people, I know
> there are couple of them but could somebody from here give advice on
> which one to choose.
>
> ***My strongest requirements I need localization support, as that
> software might need to be translated into a language other than English.
> ***Also the software should be a little bit easy to use, interms of
> administration as the clients computer literacy isnt so high enough.
> ***LAMP based software please.... :-)
> ***ofcourse open source software... :-P
>
> I know this phpBB, but what are other options?I have never played with a
> forum before.
>
>
> Thanks for the input...
>
> GR
> mrfroasty
>
Have a look at the assortment of forums (fora?) at
http://php.opensourcecms.com/scripts/show.php?catid=5&cat=Fo rums
They have sandbox sites that you can play with and get a feel for the
application.
Cheers
--
David Robley
After a number of decimal places, nobody gives a damn.
Today is Boomtime, the 61st day of Confusion in the YOLD 3175.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: open source forum
am 26.07.2009 14:50:03 von muhsin
Hello,
I need some advice in picking a PHP forum for a group of people, I know
there are couple of them but could somebody from here give advice on
which one to choose.
***My strongest requirements I need localization support, as that
software might need to be translated into a language other than English.
***Also the software should be a little bit easy to use, interms of
administration as the clients computer literacy isnt so high enough.
***LAMP based software please.... :-)
***ofcourse open source software... :-P
I know this phpBB, but what are other options?I have never played with a
forum before.
Thanks for the input...
GR
mrfroasty
--
Extra details:
OSS:Gentoo Linux
profile:x86
Hardware:msi geforce 8600GT asus p5k-se
location:/home/muhsin
language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS
Typo:40WPM
url:http://www.mzalendo.net
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: open source forum
am 26.07.2009 15:35:11 von knl
On Sun, 26 Jul 2009 14:50:03 +0200
mrfroasty wrote:
> Hello,
>
> I need some advice in picking a PHP forum for a group of people, I
> know there are couple of them but could somebody from here give
> advice on which one to choose.
>
> ***My strongest requirements I need localization support, as that
> software might need to be translated into a language other than
> English. ***Also the software should be a little bit easy to use,
> interms of administration as the clients computer literacy isnt so
> high enough. ***LAMP based software please.... :-)
> ***ofcourse open source software... :-P
>
> I know this phpBB, but what are other options?I have never played
> with a forum before.
I can strongly recommend Phorum (http://www.phorum.org/).
> Thanks for the input...
>
> GR
> mrfroasty
>
> --
> Extra details:
> OSS:Gentoo Linux
> profile:x86
> Hardware:msi geforce 8600GT asus p5k-se
> location:/home/muhsin
> language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS
> Typo:40WPM
> url:http://www.mzalendo.net
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
---
Mange venlige hilsner/Best regards
Kim Naim Lesmer
Programmer/Unix systemadministrator
Web : www.bitflop.com
E-mail : knl@bitflop.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: open source forum
am 26.07.2009 15:46:18 von muhsin
--------------070001010003070609060204
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Thanks I will have a look at those list....
GR
mrfroasty
David Robley wrote:
> mrfroasty wrote:
>
>
>> Hello,
>>
>> I need some advice in picking a PHP forum for a group of people, I know
>> there are couple of them but could somebody from here give advice on
>> which one to choose.
>>
>> ***My strongest requirements I need localization support, as that
>> software might need to be translated into a language other than English.
>> ***Also the software should be a little bit easy to use, interms of
>> administration as the clients computer literacy isnt so high enough.
>> ***LAMP based software please.... :-)
>> ***ofcourse open source software... :-P
>>
>> I know this phpBB, but what are other options?I have never played with a
>> forum before.
>>
>>
>> Thanks for the input...
>>
>> GR
>> mrfroasty
>>
>>
>
> Have a look at the assortment of forums (fora?) at
> http://php.opensourcecms.com/scripts/show.php?catid=5&cat=Fo rums
>
> They have sandbox sites that you can play with and get a feel for the
> application.
>
>
> Cheers
>
--
Extra details:
OSS:Gentoo Linux
profile:x86
Hardware:msi geforce 8600GT asus p5k-se
location:/home/muhsin
language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS
Typo:40WPM
url:http://www.mzalendo.net
--------------070001010003070609060204--
Re: open source forum
am 27.07.2009 11:18:08 von muhsin
--------------070506030904020602040401
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Thanks for the input, after playing around the choices....I think I
might go for SMF.
Looks pretty cool software, So far I have checked Phorum, phpBB and SMF
only.
The only negative thing I can tell so far is there is no gettext
infrastructure on SMF or phorum...but atleast there is a means to
translate the sofware :-)
GR
mrfroasty
K. N. Lesmer wrote:
> On Sun, 26 Jul 2009 14:50:03 +0200
> mrfroasty wrote:
>
>
>> Hello,
>>
>> I need some advice in picking a PHP forum for a group of people, I
>> know there are couple of them but could somebody from here give
>> advice on which one to choose.
>>
>> ***My strongest requirements I need localization support, as that
>> software might need to be translated into a language other than
>> English. ***Also the software should be a little bit easy to use,
>> interms of administration as the clients computer literacy isnt so
>> high enough. ***LAMP based software please.... :-)
>> ***ofcourse open source software... :-P
>>
>> I know this phpBB, but what are other options?I have never played
>> with a forum before.
>>
>
> I can strongly recommend Phorum (http://www.phorum.org/).
>
>
>> Thanks for the input...
>>
>> GR
>> mrfroasty
>>
>> --
>> Extra details:
>> OSS:Gentoo Linux
>> profile:x86
>> Hardware:msi geforce 8600GT asus p5k-se
>> location:/home/muhsin
>> language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS
>> Typo:40WPM
>> url:http://www.mzalendo.net
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> ---
> Mange venlige hilsner/Best regards
>
> Kim Naim Lesmer
> Programmer/Unix systemadministrator
>
> Web : www.bitflop.com
> E-mail : knl@bitflop.com
>
>
>
--
Extra details:
OSS:Gentoo Linux
profile:x86
Hardware:msi geforce 8600GT asus p5k-se
location:/home/muhsin
language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS
Typo:40WPM
url:http://www.mzalendo.net
--------------070506030904020602040401--
RE: open source forum
am 27.07.2009 14:19:01 von Bob McConnell
From: mrfroasty
> I need some advice in picking a PHP forum for a group of people, I
know
> there are couple of them but could somebody from here give advice on
> which one to choose.
Your request is a bit open ended. Are you looking for blogs, wiki,
message based, or what?
A couple of years ago we set up Dokuwiki as a grass roots effort in the
development group. In just over a year we had 1100 pages created. It was
so popular that management got into the act and decided to replace it
with an officially supported Confluence server. Very few of us
considered that an upgrade, but that's what happens when the PHB's get
involved.
I maintained the Dokuwiki server on a Red Hat system. It took about 30
minutes a week to keep up. It's all PHP, with numerous add-on features
and capabilities.
Bob McConnell
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: open source forum
am 27.07.2009 21:36:20 von muhsin
--------------080608040007090100040900
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sorry if I wasnt clear enough, but I was looking for forum or may be the
way you called it message board for people to discuss topics.
Mostly its going to be a political Forum where people discuss major
political topics/news about their country.
So basically my search ended up with SMF as a software to do the job.
I really appreciate the input....
Cheers.
GR
Mrfroasty
Bob McConnell wrote:
> From: mrfroasty
>
>
>> I need some advice in picking a PHP forum for a group of people, I
>>
> know
>
>> there are couple of them but could somebody from here give advice on
>> which one to choose.
>>
>
> Your request is a bit open ended. Are you looking for blogs, wiki,
> message based, or what?
>
> A couple of years ago we set up Dokuwiki as a grass roots effort in the
> development group. In just over a year we had 1100 pages created. It was
> so popular that management got into the act and decided to replace it
> with an officially supported Confluence server. Very few of us
> considered that an upgrade, but that's what happens when the PHB's get
> involved.
>
> I maintained the Dokuwiki server on a Red Hat system. It took about 30
> minutes a week to keep up. It's all PHP, with numerous add-on features
> and capabilities.
>
> Bob McConnell
>
>
--
Extra details:
OSS:Gentoo Linux
profile:x86
Hardware:msi geforce 8600GT asus p5k-se
location:/home/muhsin
language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS
Typo:40WPM
url:http://www.mzalendo.net
--------------080608040007090100040900--