salathe

Interestingly, that cheat sheet completely forgets to mention the D modifier.

I see the pattern slightly differently, something like /\b(?:[0-9A-Z]+-)+[0-9]{2}\b/ (if that makes sense).

The # are delimiters, they delimit (mark the start and end points of) the regular expression contained within. They are required because in the PCRE family of functions (preg_*) the regular expression is combined with some (optional) modifiers which affect the behaviour of the expression. The delimiters, regular expression and modifiers combined are called a pattern. Given the pattern /hello/i then the parts are: Delimiter is / Regular expression is hello Modifier is i (makes the expression match case-insensitively) The delimiters are most commonly one of /, ~, # or @. Far more characters are allowed as delimiters but it is not important at this stage to know precisely which ones. The D modifier in cags' pattern affects the behaviour of the $ character in the regular expression. Normally (i.e., without the D modifier; lets ignore multiline mode and character classes for now) the $ matches the point right at the end of the subject string, or immediately before a newline at the end of the subject string if there is one. To give an example: /def$/ matches the string "abcdef" and also "abcdef\n". When the D modifier is used, the second example (with a trailing newline) will not be matched. It is often used just to be that extra little bit sure that the subject string does not contain a trailing newline. An alternative, not wanting to confuse you, is to use the \z escape sequence which will only ever match at the very end of the subject string: /def\z/ will match "abcdef" but not "abcdef\n"

It's no use saying that something works or doesn't work without providing snippets for us to either a) tell you what's wrong, or b) run, see the problem and help you to figure it out. In answer to your questions; yes, dot can replace space and yes, there probably is.

You could also use XPath to grab the location nodes. $locations = $sxml->xpath('//location'); echo $locations[0];

Do you really need a regular expression? $variable = str_replace(";echo '\n';", "?>\n<?php", $variable); (If the string contains \r\n style newlines, use that instead of just \n.)

Modifiers that are allowed in those option settings are: i (PCRE_CASELESS) m (PCRE_MULTILINE) s (PCRE_DOTALL) x (PCRE_EXTENDED) J (PCRE_INFO_JCHANGED) (changes the local PCRE_DUPNAMES option) U (PCRE_UNGREEDY) X (PCRE_EXTRA) The point of changing these options isn't particularly to do with performance (well, it might be if you're really needing to super-duper-micro-optimise and these settings changes prove most efficient) but as with most things like this, they are tools to get a job done. Continuing from the examples already mentioned, if we wanted to match only a portion of an expression case-insensitively we could have an expression like abc[dD][eE][fF]ghi or we could temporarily change the caseless setting (in conjunction with a non-capturing group) like abc(?i:def)ghi (or abc(??i)def)ghi if we don't use the shorthand form) or we could change the setting then change it back like abc(?i)def(?-i)ghi. Note that that last pattern does something subtly different (the other two don't affect how "ghi" is matched). Of the three, for that particular case, I'd be swayed towards the second expression (using the shorthand) not for performance reasons but purely because it (to me) most clearly illustrates what the pattern is meant to do. Sure is.

[ot] Why use PHP? You're better off using <insert other, faster, language>; it's faster. [/ot]

I find that a break from "the internet" is often a good thing and in the past have gone for weeks, a month here and there, and over two months in a single span without so much as checking an email (admittedly that's a problem now, considering my chosen area of employment). Personally, I didn't notice you had gone anywhere (not that I would be expected to) but good to see you back and best wishes on living with friends.

See the last comma in this line: add_options_page('Author Data Edit','Author Data Edit',1,); P.S. There is no line 53 in that code.

"Millions" of queries all "at once" and you're only just now running into problems? There are dozens (if not more) of factors which come into play and you've not provided much information at all. Profile your system, find out where the problems lie then perhaps we can help with more focused discussions.

I think this would be a really nice candidate for a closure in PHP 5.3, something along the lines of : function create_callback($replace) { return function ($match) use ($replace) { if (ctype_upper($match[0][0])) { $replace[0] = strtoupper($replace[0]); } return $replace; }; } echo $str = preg_replace_callback('/\bgroup(?=s?\b)/i', create_callback('organization'), $str); I also changed the regular expression so that the callback doesn't need to take care of pluralising.

Do you need the pattern matching capabilities of regular expressions or would basic string functions work for you? See strstr. echo strstr($code, 'error_reporting(E_ALL ^ E_NOTICE);');

I'm not sure you understand the nature of copyright nor trademark. How much reading have you done on the subjects?

You're not calling the function.

The visibility keywords (public in your code) are only available within class definitions, not for functions.

I did prefix with "Depending on the specific needs of the OP". The post eluded to the subject string being a larger document but we all know what posters are like with their details and requirements. I believe there's a technical term for the problem of not seeing mistakes created by your own hand, but right now it escapes me. A fresh pair of eyes (be they your own or someone else's) is always useful and besides, mistakes give us something to post about.

A brief answer to the question in the topic title is, copyright.

Before posting a regular expression, can I just check that your desired output is: <p class="potMatchMenuText"><br><p class="potMatchHeading"> I only ask because it looks like that will break the HTML structure!

I'm sure folks looking at your regular expression might well experience the same. nrg_alpha's expression is slightly more optimised than cags' but there are a few points to consider. The very first and I believe foremost would be the fact that most people would be able to look at cags' and know which extensions are in the list to be matched. Can anyone glance at nrg_alpha's and say the same? (That's a rhetorical question, I'm sure some particularly gifted person could.) I believe that this holds far more weight than any of the particular improvements that might come about through optimisations like nrg_alpha presented. Next, onto the optimisation itself. The biggie in terms of optimising the expression is that the number of alternations is reduced (20 vs 29) resulting in less backtracking to do even in the worst-case scenario (i.e. the last possible alternative). However, the impact as is often the case is negligible1 in the grand-scheme of things (in real-time terms). As was eluded to in nrg_alpha's post above, an optimisation that would have a larger net effect would be to re-order the alternations so that the most common file extensions are checked first2. Of course, that would not improve the speed of execution for those extensions at the end of the list nor would the benefit be apparent if the numbers of files of each extension were similar. There are a couple of things to point out. First is the dangers of copy-and-pasting; cags made (what I interpret as) a mistake in his post (…wmv,mp3…) which was then also repeated in nrg_alpha's post and in all likelihood the OP's code. Second is that cags' pattern will stop once it has found a match: given …/abc.pptx it will report matching abc.ppt since that alternative comes first and is successfully matched. Depending on the specific needs of the OP, it might simply be worth anchoring the pattern with a $ (and of course, the D modifier) or using some other determinant to make sure the one correct extension only is matched. -- 1. This is mostly based on experience and also a very, very unscientific benchmark. 2. Ditto the note above.

Perhaps it's time for a more complete snippet so we can see how you're using the values? While you're doing that, this one works as expected: $episodes[1]['airdate'] = '2008-10-14'; $episodes[2]['airdate'] = '2008-09-16'; $episodes[3]['airdate'] = '2008-09-30'; $episodes[4]['airdate'] = '2008-09-23'; function recordcompare($a, $b) { return strnatcmp($a['airdate'], $b['airdate']); } uasort($episodes, 'recordcompare'); print_r($episodes);

You need to use the values for the airdates in the comparison like return strnatcmp($a["airdate"], $b["airdate"]);

Note: It seems you've solve this already but I typed a reply so I'm going to post it! arsort won't help you because although it does sort the items, the keys are preserved meaning that (as you can see) index zero still belongs with the value 0.jpg. sort won't help because it does re-index the array but sorts in ascending order. What you're probably after is rsort (rsort($files_list, SORT_NUMERIC);). With that, the sorted $files_list[0] will be 3.jpg.

[ot]It's not when editing, the problem is how post text is parsed when viewing posts/topics. SMF is parsing print_r text (Array( [0] => ... [1] => ... )) like in the first post of this thread. I know everyone should be using code tags, and that we all know what the poster means when things get "broken" like that, but surely** it can't be difficult to persuade SMF to only parse tags like that when wrapped with the appropriate wrapping tags ([ul] or whatever) or ignore them if preceded by the particular sequence of characters in a print_r value. I don't know, maybe that's too much hard work and we just just yell at people to use code tags and/or ignore the problem. ** Famous last words.[/ot]

Possible, yes. The solution would depend entire on what precisely you want to do ("send a fax, duh"). Is the fax machine going to be local to the server hosting the PHP, or would using external (web) services be OK?