php-general Digest 25 Jul 2009 02:53:29 -0000 Issue 6248
Topics (messages 295806 through 295831):
Re: Question on code profiling
295806 by: Andrew Ballard
295809 by: Andrew Ballard
Tidy question about the config args
295807 by: Al
Re: This is the kind of [expletives deleted] answer that is certain to prevent
bugs being reported.
295808 by: Kyle Smith
295810 by: Per Jessen
295811 by: Kyle Smith
295812 by: Jim Lucas
295813 by: Per Jessen
295814 by: Kyle Smith
295815 by: Per Jessen
295816 by: Ben Dunlap
295818 by: Daniel Brown
295824 by: Per Jessen
295825 by: Per Jessen
295826 by: Daniel Brown
295827 by: Per Jessen
295828 by: Robert Cummings
295829 by: Lupus Michaelis
295830 by: Greg Beaver
PHP as Language
295817 by: Martin Scotta
295819 by: Kyle Smith
295820 by: b
295821 by: Shawn McKenzie
295822 by: Mari Masuda
295823 by: Greg Beaver
prepending concatenating assignment operator
295831 by: Daniel Kolbo
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Fri, Jul 24, 2009 at 2:27 AM, Lupus
Michaelis<mickael+...@lupusmic.org> 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
--- End Message ---
--- Begin Message ---
On Thu, Jul 23, 2009 at 11:31 PM, Andrew Ballard<aball...@gmail.com> 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
--- End Message ---
--- Begin Message ---
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 xxxx<green>xxxxxxx</green>xxxxxxxxx
to tidy_parse_string() and get this report from the tidy_get_error_buffer()
line 1 column 5 - Error: <green> is not recognized!
line 1 column 5 - Warning: discarding unexpected <green>
line 1 column 19 - Warning: discarding unexpected </green>
PHP does not report any errors.
What's the point of having new, custom tags if functions ignore them?
What am I missing?
Thanks.........
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
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)
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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)
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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)
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Fri, Jul 24, 2009 at 13:18, Per Jessen<p...@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
--- End Message ---
--- Begin Message ---
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)
--- End Message ---
--- Begin Message ---
Daniel Brown wrote:
> On Fri, Jul 24, 2009 at 13:18, Per Jessen<p...@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)
--- End Message ---
--- Begin Message ---
On Fri, Jul 24, 2009 at 15:25, Per Jessen<p...@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
--- End Message ---
--- Begin Message ---
Daniel Brown wrote:
> On Fri, Jul 24, 2009 at 15:25, Per Jessen<p...@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)
--- End Message ---
--- Begin Message ---
Per Jessen wrote:
Daniel Brown wrote:
On Fri, Jul 24, 2009 at 15:25, Per Jessen<p...@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
--- End Message ---
--- Begin Message ---
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 <http://lupusmic.org/pro/>
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Hi all
Is there a formal definition for the php language?
Where I can found it?
I've STW with no results.
--
Martin Scotta
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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
`
--- End Message ---
