php-general Digest 24 Jul 2009 12:41:20 -0000 Issue 6247
php-general Digest 24 Jul 2009 12:41:20 - Issue 6247
Topics (messages 295775 through 295805):
Re: Undefined Index ...confusion] (RESOLVED)
295775 by: Miller, Terion
Re: Renaming all variables in a repository
295776 by: Stuart
Question on code profiling
295777 by: Andrew Ballard
295778 by: Robert Cummings
295780 by: Ben Dunlap
295781 by: Andrew Ballard
295782 by: Andrew Ballard
295783 by: Jonathan Tapicer
295784 by: Ben Dunlap
295792 by: Andrew Ballard
295804 by: Lupus Michaelis
Re: Compare PHP settings of two different servers
295779 by: Ben Dunlap
Re: Writing to CD/DVD?
295785 by: Clancy
295786 by: Diogo Neves
295787 by: Nitsan Bin-Nun
Re: Doubt regarding session_destroy() in PHP 5
295788 by: Lupus Michaelis
Re: Mediawiki's url confusion
295789 by: Dengxule
295791 by: sean greenslade
295800 by: Paul M Foster
295803 by: Dengxule
Re: Structure of PHP files
295790 by: Lupus Michaelis
A form and an array
295793 by: Jason Carson
295794 by: David Robley
295795 by: Jason Carson
295796 by: David Robley
295797 by: Jason Carson
295798 by: Warren Vail
295799 by: Jason Carson
295801 by: Dengxule
295802 by: Jason Carson
This is the kind of [expletives deleted] answer that is certain to prevent bugs
being reported.
295805 by: Per Jessen
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
--
---BeginMessage---
Thanks
On 7/23/09 9:52 AM, Kyle Smith kyle.sm...@inforonics.com wrote:
Sorry, list, I did a reply instead of a reply-to-all. This is what I
sent to Miller, Terion
Miller, Terion wrote:
Thanks for the link Kyle!! Great thing there...(seriously I didn't know...I
learn something everyday)
Anyways the link to my script is: http://pastebin.ca/1504393
Your email client is annoying, it doesn't quote. Haha.
Anyway, so, you're loading up that array with arrays of arrays, here:
1.
$position = 1;
2.
3.
while ($row = mysql_fetch_array
http://www.php.net/mysql_fetch_arrayhttp://www.php.net/mysql_fetch_array($result))
4.
{
5.
$_SESSION['fullRestaurantList'][$position] = $row;
6.
$position++;
7.
}
8.
9.
$_SESSION['totalNumberOfRestaurants'] = $position;
So, if you get 7 rows. Your array will have:
Array = (Row 1 Data)
Array = (Row 2 Data)
.. etc
You do not have ['fullRestaurantList']['ID']. In the page you're
referencing you use something like
$_SESSION['fullRestaurantList'][$i]['SomeValue']. I assume $i is the
Position in the array, so you likely want to use
$_SESSION['fullRestaurantList'][$i]['ID'] to get the ID field from that row.
If you need a quick dump to better understand what data you have in your
session, try making a page called session_dump.php in the same directory
with this source:
pre? print_r($_SESSION) ?/pre
That will give you a good idea of what your session array looks like,
and you should see clearly that ['fullRestaurantList']['ID'] does not exist.
Hope this helps!
- Kyle
---End Message---
---BeginMessage---
2009/7/23 Eddie Drapkin oorza...@gmail.com:
Hey all,
we've got a repository here at work, with something like 55,000 files
in it. For the last few years, we've been naming $variables_like_this
and functions_the_same($way_too). And now we've decided to switch to
camelCasing everything and I've been tasked with somehow determining
if it's possible to automate this process. Usually, I'd just use the
IDE refactoring functionality, but doing it on a
per-method/per-function and a per-variable basis would take weeks, if
not longer, not to mention driving everyone insane.
I've tried with regular expressions, but I can't make them smart
enough to distinguish between builtins and userland code. I've looked
at the tokenizer and it seems to be the right way forward, but that's
also a huge project to get that to work.
I was wondering if anyone had had any experience doing this and could
either point me in the right direction or just down and out tell me
how to do it.
I'd question the wisdom of doing such a thing at all. When it comes to
coding standards the important thing is not what they are, just that
they exist and are observed by everybody.
This sounds like a colossal waste of time, whether you can find an
automated method or not, for no apparent gain. Seriously, what's the
benefit of using camel over underscores? Sounds like a decision made
by a manager who feels the need to create work when none is actually
required.
-Stuart
--
php-general Digest 25 Jul 2009 02:53:29 -0000 Issue 6248
php-general Digest 25 Jul 2009 02:53:29 - 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 -- ---BeginMessage--- On Fri, Jul 24, 2009 at 2:27 AM, Lupus Michaelismickael+...@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--- ---BeginMessage--- On Thu, Jul 23, 2009 at 11:31 PM, Andrew Ballardaball...@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--- ---BeginMessage--- 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 greenxxx/greenx 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--- ---BeginMessage--- Per Jessen wrote: See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per I don't mean to be rude, but I have never heard of or used these functions and never written a multi-lingual PHP site. I RTFM'd and found this: http://us.php.net/manual/en/function.setlocale.php Then I read the first sentence defining the second parameter, which states: If /locale/ is *NULL* or the empty string //, the locale names will be set from the values of environment variables with the same names as the above categories, or from LANG. Pretty straight-forward. ---End Message--- ---BeginMessage--- 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:
[PHP] Re: Question on code profiling
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 Seeking for a position http://lupusmic.org/pro/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per -- Per Jessen, Zürich (23.1°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Question on code profiling
On Fri, Jul 24, 2009 at 2:27 AM, Lupus Michaelismickael+...@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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Tidy question about the config args
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 greenxxx/greenx 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per I don't mean to be rude, but I have never heard of or used these functions and never written a multi-lingual PHP site. I RTFM'd and found this: http://us.php.net/manual/en/function.setlocale.php Then I read the first sentence defining the second parameter, which states: If /locale/ is *NULL* or the empty string //, the locale names will be set from the values of environment variables with the same names as the above categories, or from LANG. Pretty straight-forward.
Re: [PHP] Question on code profiling
On Thu, Jul 23, 2009 at 11:31 PM, Andrew Ballardaball...@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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Kyle Smith wrote: Per Jessen wrote: See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per I don't mean to be rude, but I have never heard of or used these functions and never written a multi-lingual PHP site. I RTFM'd and found this: http://us.php.net/manual/en/function.setlocale.php Then I read the first sentence defining the second parameter, which states: If /locale/ is *NULL* or the empty string //, the locale names will be set from the values of environment variables with the same names as the above categories, or from LANG. Pretty straight-forward. Did you bother reading the bug report? The PHP CLI ignores the locale setting from the environment such as set by setting LC_ALL. Your quoting from the manual does not change that. Now, if you can find a place in the manual that says the CLI will ignore whatever locale settings are set in the environment, we can talk again. /Per -- Per Jessen, Zürich (18.3°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: Kyle Smith wrote: Per Jessen wrote: See http://bugs.php.net/?id=48612 Thank you for taking the time to write to us, but this is not a bug. And RTFM. (RTFM is my interpretation of the rest). And that only took a little more than a month. Thanks very much. Can anyone here tell me why the CLI behaviour reported is not a bug? An explicit manual reference will do. Btw, I brought it up here already: http://marc.info/?l=php-generalm=124487699630514w=2 /Per I don't mean to be rude, but I have never heard of or used these functions and never written a multi-lingual PHP site. I RTFM'd and found this: http://us.php.net/manual/en/function.setlocale.php Then I read the first sentence defining the second parameter, which states: If /locale/ is *NULL* or the empty string //, the locale names will be set from the values of environment variables with the same names as the above categories, or from LANG. Pretty straight-forward. Did you bother reading the bug report? The PHP CLI ignores the locale setting from the environment such as set by setting LC_ALL. Your quoting from the manual does not change that. Now, if you can find a place in the manual that says the CLI will ignore whatever locale settings are set in the environment, we can talk again. /Per I don't think your aggressive attitude to the situation is helping anyone here. The manual *explicitly* states that using setlocale(LC_xyz,'') will use the environment variable setting for that LC_xyz option. This *implies* that, by default, those environment variables are not used. Perhaps it should use the environment variables, instead? At any rate, it's not a bug, since someone(s) did it that way on purpose. You could file a feature request.
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Kyle Smith wrote:
Per Jessen wrote:
Kyle Smith wrote:
Per Jessen wrote:
See http://bugs.php.net/?id=48612
Thank you for taking the time to write to us, but this is not
a bug. And RTFM. (RTFM is my interpretation of the rest).
And that only took a little more than a month. Thanks very much.
Can anyone here tell me why the CLI behaviour reported is not a bug?
An explicit manual reference will do.
Btw, I brought it up here already:
http://marc.info/?l=php-generalm=124487699630514w=2
/Per
I don't mean to be rude, but I have never heard of or used these
functions and never written a multi-lingual PHP site. I RTFM'd and
found this:
http://us.php.net/manual/en/function.setlocale.php
Then I read the first sentence defining the second parameter, which
states: If /locale/ is *NULL* or the empty string //, the locale
names will be set from the values of environment variables with the
same names as the above categories, or from LANG.
Pretty straight-forward.
Did you bother reading the bug report? The PHP CLI ignores the locale
setting from the environment such as set by setting LC_ALL. Your
quoting from the manual does not change that. Now, if you can find a
place in the manual that says the CLI will ignore whatever locale
settings are set in the environment, we can talk again.
/Per
I don't think your aggressive attitude to the situation is helping
anyone here. The manual *explicitly* states that using
setlocale(LC_xyz,'') will use the environment variable setting for that
LC_xyz option. This *implies* that, by default, those environment
variables are not used.
Perhaps it should use the environment variables, instead? At any rate,
it's not a bug, since someone(s) did it that way on purpose. You
could file a feature request.
Sorry, just want to point out a difference, that I see, in the code
examples. Not trying to start anything here...
So, what does the example you provide have to do with the ops code
example in the bug report?
OPS example code from bug report
LC_ALL=de_DE.utf8 php -r print strftime('%B');
your example
setlocale(LC_xyz,'')
I don't see him using the above function in his example.
From what I can tell, the op is trying to set the locale /AT/ the cli,
not from within the script.
I guess my first debugging question would be:
Can you successfully set other LC_xyz categories, besides the LC_ALL, in
the same manor that your example shows?
If it works with the others (LC_COLLATE, LC_CTYPE, etc...) then I
/would/ call this a bug. Unless it has been explicitly stated somewhere
that the op has not found that This works with all but the LC_ALL
category.
Just my 2 bits worth.
Jim Lucas
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Kyle Smith wrote: I don't think your aggressive attitude to the situation is helping anyone here. The manual *explicitly* states that using setlocale(LC_xyz,'') will use the environment variable setting for that LC_xyz option. This *implies* that, by default, those environment variables are not used. Which is exactly the bug I reported. An application that deliberately ignores the locale setting passed from the environment is buggy unless it is clearly documented. Why should a developer be forced to be aware of the locale when it has already been done for him? That is just dim. Kyle, imagine this - assume the default locale for the PHP CLI is Greek. In everyone of your scripts you'd have to call setlocale() to get it to accept your otherwise default US locale. Where's the sense in that when your machine already has the correct locale? As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. /Per -- Per Jessen, Zürich (18.3°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Jim Lucas wrote:
Kyle Smith wrote:
Per Jessen wrote:
Kyle Smith wrote:
Per Jessen wrote:
See http://bugs.php.net/?id=48612
Thank you for taking the time to write to us, but this is not
a bug. And RTFM. (RTFM is my interpretation of the rest).
And that only took a little more than a month. Thanks very much.
Can anyone here tell me why the CLI behaviour reported is not a bug?
An explicit manual reference will do.
Btw, I brought it up here already:
http://marc.info/?l=php-generalm=124487699630514w=2
/Per
I don't mean to be rude, but I have never heard of or used these
functions and never written a multi-lingual PHP site. I RTFM'd and
found this:
http://us.php.net/manual/en/function.setlocale.php
Then I read the first sentence defining the second parameter, which
states: If /locale/ is *NULL* or the empty string //, the locale
names will be set from the values of environment variables with the
same names as the above categories, or from LANG.
Pretty straight-forward.
Did you bother reading the bug report? The PHP CLI ignores the locale
setting from the environment such as set by setting LC_ALL. Your
quoting from the manual does not change that. Now, if you can find a
place in the manual that says the CLI will ignore whatever locale
settings are set in the environment, we can talk again.
/Per
I don't think your aggressive attitude to the situation is helping
anyone here. The manual *explicitly* states that using
setlocale(LC_xyz,'') will use the environment variable setting for that
LC_xyz option. This *implies* that, by default, those environment
variables are not used.
Perhaps it should use the environment variables, instead? At any rate,
it's not a bug, since someone(s) did it that way on purpose. You
could file a feature request.
Sorry, just want to point out a difference, that I see, in the code
examples. Not trying to start anything here...
So, what does the example you provide have to do with the ops code
example in the bug report?
OPS example code from bug report
LC_ALL=de_DE.utf8 php -r print strftime('%B');
your example
setlocale(LC_xyz,'')
I don't see him using the above function in his example.
From what I can tell, the op is trying to set the locale /AT/ the cli,
not from within the script.
I guess my first debugging question would be:
Can you successfully set other LC_xyz categories, besides the LC_ALL, in
the same manor that your example shows?
If it works with the others (LC_COLLATE, LC_CTYPE, etc...) then I
/would/ call this a bug. Unless it has been explicitly stated somewhere
that the op has not found that This works with all but the LC_ALL
category.
Just my 2 bits worth.
Jim Lucas
I agree entirely, Jim. Would be a good test. My guess is that they all
behave the same way, based on how the setlocale() documentation reads.
- Kyle
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Jim Lucas wrote: From what I can tell, the op is trying to set the locale /AT/ the cli, not from within the script. Exactly Jim. A typical Linux installation in France/Germany/Greece/ Russia/whereever will have an appropriate environment (e.g. LC_ALL) set such that unix commands such as date and ls will display the information as appropriate for French, German, Greek and Russian. I guess my first debugging question would be: Can you successfully set other LC_xyz categories, besides the LC_ALL, in the same manor that your example shows? I guess it might be worth trying, but I think it's highly unlikely that any of the other settings will be accepted either. /Per -- Per Jessen, Zürich (18.3°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: Which is exactly the bug I reported. An application that deliberately ignores the locale setting passed from the environment is buggy unless it is clearly documented. Why should a developer be forced to be aware of the locale when it has already been done for him? That is just dim. In what sense is this a bug in PHP, though? If anything it is a bug in the documentation, but for Kyle at least, the existing documentation makes it clear that the pre-existing environment variable be ignored unless you call setlocale with a NULL or empty second argument. I had the same experience as Kyle, when I read the documentation at http://us.php.net/manual/en/function.setlocale.php -- and I thought to read that documentation because I first searched the bug database for LC_ALL (as requested at http://bugs.php.net/how-to-report.php ). Here's what I found: http://bugs.php.net/bug.php?id=48876 Which shed some light on the whole issue for me. After reading that bug report and the setlocale() manual page, it was clear to me that the PHP developers intended for PHP to initially ignore the environment variable LC_ALL. Your sense is that the developers made a bad design decision here, and perhaps you're right, but a bug is a mistake in the code that causes the software to do something other than what the developers intended. There's no bug here. As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. I thought the response on the bug was awfully polite under the circumstances. Again, from bugs.php.net's How to Report a Bug: 'Take special note of that word in bold above. The people who are going to help you with a bug you report are *volunteers*. Not only are you not paying them to help you, but nobody else is either. So, to paraphrase the immortal words of Bill and Ted, be excellent to them.' Have you read the classic How to Ask Questions the Smart Way? http://catb.org/~esr/faqs/smart-questions.html Ben -- Twitter: @bdunlap -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP as Language
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.
On Fri, Jul 24, 2009 at 13:18, Per Jessenp...@computer.org wrote: As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. Per; We only reply like that when writing to you. Everyone else gets nice responses, but well, we just plain hate you, man. We took a vote and it was unanimous. Coincidentally, we also spoke with some of your relatives, and as it turns out, they want you out of the family as well. Sorry to be the bearer of bad news. Good luck in life. In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. That said, you're not the first (and certainly won't be the last) to feel miffed about it. The responses are not very diplomatic to those who have a good grasp of the English language, and the lack of inflection offered by printed words doesn't help. (P.S. - Stop crying. Your family didn't really say they want you out, but if they do, you can move to the US and have the shed in my back yard. Bring a blanket. ;-P) -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Check out our great hosting and dedicated server deals at http://twitter.com/pilotpig -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP as Language
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
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
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
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
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=281094view=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.
Ben Dunlap wrote: Per Jessen wrote: Which is exactly the bug I reported. An application that deliberately ignores the locale setting passed from the environment is buggy unless it is clearly documented. Why should a developer be forced to be aware of the locale when it has already been done for him? That is just dim. In what sense is this a bug in PHP, though? Well, I guess it is only a bug if one expects PHP to behave like a normal Unixy application. Mea culpa, perhaps. Have you read the classic How to Ask Questions the Smart Way? http://catb.org/~esr/faqs/smart-questions.html Ben -- Twitter: @bdunlap I can't help it, but I feel uncannily tempted to write you twit. /Per -- Per Jessen, Zürich (17.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Daniel Brown wrote: On Fri, Jul 24, 2009 at 13:18, Per Jessenp...@computer.org wrote: As for being aggressive - well, being fobbed off with an RTFM when 1) I've spent some time and effort in testing, documenting and reporting the bug, and 2) the behaviour is at best undocumented, well, yes, it p.. me off. It's just not professional and not at all conducive to getting any more bugs reported. Per; We only reply like that when writing to you. Everyone else gets nice responses, but well, we just plain hate you, man. We took a vote and it was unanimous. Coincidentally, we also spoke with some of your relatives, and as it turns out, they want you out of the family as well. Sorry to be the bearer of bad news. Good luck in life. I knew it. I did. There's a good reason I haven't lived in my home country for some 17 years . :-) In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. /Per -- Per Jessen, Zürich (17.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
On Fri, Jul 24, 2009 at 15:25, Per Jessenp...@computer.org wrote: Daniel Brown wrote: In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. At the risk of sounding redundant or dismissive myself (which I think you know me well enough by now to know is not the case), the best I could suggest would be to file a bug report pertaining to the wording of the responses. In all honesty, I don't see much being done in the way of changing that right away, but I could be wrong (which, in this case, would be welcome). By the way it's Friday night there. Why the heck are you still sitting in front of a computer?!? -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Check out our great hosting and dedicated server deals at http://twitter.com/pilotpig -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Daniel Brown wrote: On Fri, Jul 24, 2009 at 15:25, Per Jessenp...@computer.org wrote: Daniel Brown wrote: In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. At the risk of sounding redundant or dismissive myself (which I think you know me well enough by now to know is not the case), I do. (it's funny how you can get to know someone like that without ever having met them, but it's a fact). the best I could suggest would be to file a bug report pertaining to the wording of the responses. In all honesty, I don't see much being done in the way of changing that right away, but I could be wrong (which, in this case, would be welcome). I was actually being quite deliberate when I used the word braindead before - the automated click-of-a-button response may have its use, but one should always be careful with when to use it. Is there any way of filing a a bugreport on jani? Nah, perhaps I should file a doc-bug, but to be honest, I can't be bothered when the PHP project can't. It's a sad state of affairs. By the way it's Friday night there. Why the heck are you still sitting in front of a computer?!? It's 21:55 here and I'm really just a sad old git :-) Well, I've been busy keeping an eye on my 5 year old most of the day. His favourite playmate from next door was away today, which meant I didn't get to do much work until around 1830. (Amongst other things, I have a decidedly difficult mysql core dump I'm trying to capture). /Per, signing off for the night. -- Per Jessen, Zürich (17.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: Daniel Brown wrote: On Fri, Jul 24, 2009 at 15:25, Per Jessenp...@computer.org wrote: Daniel Brown wrote: In reality, those are canned responses. Jani didn't type that up himself, he just selected it from a drop-down that we have. In all honesty, that only makes it worse. To make an effort to improve on things only to be told to eff off by a machine operated by a braindead individual. It's worded very directly so as to reach a broad scope of folks --- many of whom don't speak English as well as yourself. So don't take offense, because it's not meant to be either offensive or dismissive. Too late Dan - offense already taken. The response was dimwitted, offensive and dismissive, intended or not. At the risk of sounding redundant or dismissive myself (which I think you know me well enough by now to know is not the case), I do. (it's funny how you can get to know someone like that without ever having met them, but it's a fact). the best I could suggest would be to file a bug report pertaining to the wording of the responses. In all honesty, I don't see much being done in the way of changing that right away, but I could be wrong (which, in this case, would be welcome). I was actually being quite deliberate when I used the word braindead before - the automated click-of-a-button response may have its use, but one should always be careful with when to use it. Is there any way of filing a a bugreport on jani? Nah, perhaps I should file a doc-bug, but to be honest, I can't be bothered when the PHP project can't. It's a sad state of affairs. By the way it's Friday night there. Why the heck are you still sitting in front of a computer?!? It's 21:55 here and I'm really just a sad old git :-) Well, I've been busy keeping an eye on my 5 year old most of the day. His favourite playmate from next door was away today, which meant I didn't get to do much work until around 1830. (Amongst other things, I have a decidedly difficult mysql core dump I'm trying to capture). I understand where you're coming from, and I've been on the same road before with PHP bug reports. And while I remember being really annoyed, especially when it turned out to actually be a bug, I have to say if you define your case clearly and state where either the documentation isn't clear enough, or the code works in an unexpected fashion, then they will usually give it the due consideration. Don't forget nobody is being paid to handle bug reports, it's all on a volunteer basis and I'm quite certain they get oodles of real bogus bugs. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: This is the kind of [expletives deleted] answer that is certain to prevent bugs being reported.
Per Jessen wrote: See http://bugs.php.net/?id=48612 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/ -- 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.
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
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
Andrew Ballard wrote: On Thu, Jul 23, 2009 at 11:31 PM, Andrew Ballardaball...@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 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
