[PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.

[Per Jessen]

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

-- 
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] Re: Question on code profiling

[Andrew Ballard]

On Fri, Jul 24, 2009 at 2:27 AM, Lupus
Michaelis wrote:
> Andrew Ballard a écrit :
>>
>> I'm trying to profile a site on our development server to see why it
>> takes around 4 seconds to generate a pretty basic page.
>
>  Last time I seen this is when I did validate DOM Document without DTD on
> local disk :D
>
>  Can you put somewhere the essential code that take time ?
>
> --
> Mickaël Wolff aka Lupus Michaelis
> http://lupusmic.org

Not really. I haven't written much for this site yet, so the bulk of
the code is just the framework itself. If I can't find anything, I'll
probably be posting on the ZF mailing list next. I have had really
good experiences with ZF on a couple shared-hosting Linux servers I've
used, but performance on Windows so far has been dismal.

Andrew

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Tidy question about the config args

[Al]

I have a question about using the $config arguments with tidy_parse_string() and 
 tidy_repair_string() etc.


The functions seem to totally ignore
new-blocklevel-tags
new-empty-tags  
new-inline-tags

E.g., I have in my config array some custom tags
[new-inline-tags] => blue,bold,green,italic,red,underline

I feed this string 

to tidy_parse_string() and get this report from the tidy_get_error_buffer()

line 1 column 5 - Error:  is not recognized!
line 1 column 5 - Warning: discarding unexpected 
line 1 column 19 - Warning: discarding unexpected 

PHP does not report any errors.

What's the point of having new, custom tags if functions ignore them?

What am I missing?

Thanks.


--
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]

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.

Re: [PHP] Question on code profiling

[Andrew Ballard]

On Thu, Jul 23, 2009 at 11:31 PM, Andrew Ballard wrote:
> From what I can tell, the numbers I see in WinCacheGrind
> look like they are off by about a factor of 10 pretty
> uniformly.
>
> Andrew
>

Apparently the difference is indeed WinCacheGrind, as a number of
other people have left comments on the project site that the values it
reports need to be multiplied by 10. Now that I know the numbers are
"right" comes the fun part.  :-\

Andrew

-- 
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]

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


-- 
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.

[Kyle Smith]

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.

Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.

[Jim Lucas]

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: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.

[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. 

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.

[Kyle Smith]

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

Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.

[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. 

> 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.

[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

[PHP] PHP as Language

[Martin Scotta]

Hi all

Is there a formal definition for the php language?
Where I can found it?

I've STW with no results.

-- 
Martin Scotta

-- 
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]

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 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.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] PHP as Language

[Kyle Smith]

Martin Scotta wrote:

Hi all

Is there a formal definition for the php language?
Where I can found it?

I've STW with no results.

  
Not sure if this is what you mean, but PHP stands for "PHP:  Hypertext 
Processor"


- Kyle

Re: [PHP] PHP as Language

[b]

On 07/24/2009 02:06 PM, Kyle Smith wrote:

Martin Scotta wrote:

Hi all

Is there a formal definition for the php language?
Where I can found it?

I've STW with no results.


Not sure if this is what you mean, but PHP stands for "PHP: Hypertext
Processor"

- Kyle



I think Martin is looking for the formal definition of the language, not 
the name. Wikipedia has a bunch of links worth checking:


http://en.wikipedia.org/wiki/PHP#Notes

Nothing jumps out at me, though.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: PHP as Language

[Shawn McKenzie]

Martin Scotta wrote:
> Hi all
> 
> Is there a formal definition for the php language?
> Where I can found it?
> 
> I've STW with no results.
> 

What is a definition?  Do you mean specification like ECMA or ANSI?

-- 
Thanks!
-Shawn
http://www.spidean.com

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: PHP as Language

[Mari Masuda]

On Jul 24, 2009, at 11:30, Shawn McKenzie wrote:


Martin Scotta wrote:

Hi all

Is there a formal definition for the php language?
Where I can found it?

I've STW with no results.



What is a definition?  Do you mean specification like ECMA or ANSI?



I think he meant Backus Naur, but I could be wrong.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: PHP as Language

[Greg Beaver]

Martin Scotta wrote:
> Hi all
> 
> Is there a formal definition for the php language?
> Where I can found it?
> 
> I've STW with no results.

http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_parser.y?revision=281094&view=markup

which is Zend/zend_language_parser.y in the source code of PHP.

Greg

-- 
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]

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.

[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 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.

[Daniel Brown]

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), 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.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.

[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 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.

[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

[PHP] Re: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.

[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: [PHP] This is the kind of [expletives deleted] answer that iscertain to prevent bugs being reported.

[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

[PHP] prepending concatenating assignment operator

[Daniel Kolbo]

Hello,

I know the appending concatenating assignment operator:
$str_name = "Foobar";
$str_name .= " Sr";
echo $str_name;//Foobar Sr

But is there a shortcut assignment operator for prepending concatenation?

$str_name = "Foobar";
//$str_name =. "Mr ";
// i know this is not allowed, but is there some shorcut?
$str_name = "Mr " . $str_name;
echo $str_name;//Mr Foobar

Just curious.

Thanks,
dK
`

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Question on code profiling

[Daniel Kolbo]

Andrew Ballard wrote:
> On Thu, Jul 23, 2009 at 11:31 PM, Andrew Ballard wrote:
>> From what I can tell, the numbers I see in WinCacheGrind
>> look like they are off by about a factor of 10 pretty
>> uniformly.
>>
>> Andrew
>>
> 
> Apparently the difference is indeed WinCacheGrind, as a number of
> other people have left comments on the project site that the values it
> reports need to be multiplied by 10. Now that I know the numbers are
> "right" comes the fun part.  :-\
> 
> Andrew
> 
Is this factor of 10 business only for ZF on Windows IIS or for Linux too?
thanks,
dK
`

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php