php-general Digest 28 Nov 2010 20:54:47 -0000 Issue 7059
php-general Digest 28 Nov 2010 20:54:47 - Issue 7059 Topics (messages 309734 through 309735): I have a question about MLM 309734 by: Ron Orth 309735 by: Tommy Pham 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--- Hello,was searching online for MLM platforms to use and came across your information with MLM can you tell me, how do you tie in with this and how is it working for you. Sincerely, Ron Orth ---End Message--- ---BeginMessage--- -Original Message- From: Ron Orth [mailto:dort...@gmail.com] Sent: Sunday, November 28, 2010 7:15 AM To: php-gene...@lists.php.net Subject: [PHP] I have a question about MLM Hello,was searching online for MLM platforms to use and came across your information with MLM can you tell me, how do you tie in with this and how is it working for you. Sincerely, Ron Orth Ron, Which MLM are you referring you? ;) Multi-Level Marketing? Mid-Level Manager? Medicare Learning Network? Marxism-Leninism-Maoism? Regards, Tommy ---End Message---
Re: [PHP] I have a question about MLM
On Sun, Nov 28, 2010 at 15:54, Tommy Pham tommy...@gmail.com wrote: Which MLM are you referring you? ;) Multi-Level Marketing? Mid-Level Manager? Medicare Learning Network? Marxism-Leninism-Maoism? It's likely SPAM-testing or email harvesting. The exact same vague email was sent to the php-db@ list during the same minute. I'd ignore it, and if the OP wants a real response, he can try again in a more intelligent form. -- /Daniel P. Brown Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting (866-) 725-4321 http://www.parasane.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] preg_match fails to resolve variable as a subject
On 27 November 2010 04:45, Da Rock php-l...@herveybayaustralia.com.au wrote:
On 11/27/10 13:51, Tamara Temple wrote:
On Nov 26, 2010, at 7:28 PM, Da Rock wrote:
On 11/27/10 00:57, Richard Quadling wrote:
On 26 November 2010 00:07, Da Rockphp-l...@herveybayaustralia.com.au
wrote:
preg_match(/(\d{1,3})(\.)$/, exec($mixer . ' ' . $command),$matches)
Can you ...
var_dump(exec($mixer . ' ' . $command));
I wonder if the output includes a new line which you are not
accounting for in the regex.
Haven't tried yet, but isn't that what $ is for? End of line?
$ matches end of line, but since your last match expression is to match
explicitly the character '.' before end of line, and there's a newline, it
won't match. Again, use trim() to get rid of the newline character at the
end of the string returned by exec(). Looking at the output or
And exec only gives one line- the last line of the output of the command.
You have to provide a reference to an array for the entire output.
var_dump gives:
string(41) Mixer vol is currently set to 75:75
It also looks like \d{1,3}\. won't match anything in the output string
given by the command.
Thank you for that- that did it. I removed the \.
I am a little confused though; that regex was tested on several test sites
and was deemed accurate on them, and one of them actually supplied the
preg_match code. And if I run the command on a shell it actually outputs
exactly the right subject for the regex- not to mention it got printed
inadvertently (using system() ) via the php exactly the same. So I don't
think I missed it somehow.
What I have constantly seen come up (shell and php/html) is: Mixer vol is
currently set to 75:75. (including the period)
Don't get me wrong- you guys make sense; my system doesn't. I need to get to
the bottom of this so I can ensure my code will port well. I don't want to
get it all working and find it breaks when I run it on another system,
albeit same OS (FreeBSD). Could be updates or variations of releases.
Just to check again, I ran the command on the shell again and sure enough
the period is no longer there- but I can't for the life of me figure out
when that changed as this code has never worked (and yes, I added in the \.
to match the end of line because it originally wasn't working). Another
great mystery? Weird... :)
Thanks again guys.
The regex is a valid regex. It's just useless for the data you are providing it.
I'm wondering what is missing from your output? The var_dump says the
text is a 41 character string, but the data you provided only has 36
characters in it.
What elements of the string do you want to capture?
/:(\d++)/ would catch the number after the :
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Problem with RegEx for BBCode
On 27 November 2010 13:57, Asmann, Roland roland.asm...@adesso.at wrote: Hi all, I am playing around with PHP and BBCodes and have found some regex's that should transform my BBCode into correct HTML when rendering. However, I have found that if the BBCode is not correct (eg missing closing tag), the regex completely eats my input and my page is empty! The regex I'm using is: /\[i\]((\s|.)+?)\[\/i\]/ And with an input like: This is [i]italic. I get nothing back. What I would like is that when no closing tag is found, the opening tag should just be shown as-is. Anybody have any idea how I can do this? Thanks! -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I think this is a common issue with regex. Trying to use Regex as a parser is no good. At best, regex can be used as a tokenizer. It has limited ability to handle the nesting. The input you gave has no closing [/i], so the regex can't match the string, so nothing is returned. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Disk IO performance
There are many things that everybody knows about optimizing PHP code. One of them is that one of the most expensive parts of the process is loading code off of disk and compiling it, which is why opcode caches are such a bit performance boost. The corollary to that, of course, is that more files = more IO and therefore more of a performance hit. But... this is 'effin 2010. It's almost bloody 2011. Operating systems are smart. They already have 14 levels of caching built into them from hard drive micro-controller to RAM to CPU cache to OS. I've heard from other people (who should know) that the IO cost of doing a file_exists() or other stat calls is almost non-existent because a modern OS caches that, and with OS-based file caching even reading small files off disk (the size that most PHP source files are) is not as slow as we think. Personally, I don't know. I am not an OS engineer and haven't benchmarked such things, nor am I really competent to do so. However, it makes a huge impact on the way one structures a large PHP program as the performance trade- offs of huge files with massive unused code (that has to be compiled) vs the cost of reading lots of separate files from disk (more IO) is highly dependent on the speed of the aforementioned IO and of compilation. So... does anyone have any actual, hard data here? I don't mean I think or in my experience. I am looking for hard benchmarks, profiling, or writeups of how OS (Linux specifically if it matters) file caching works in 2010, not in 1998. Modernizing what everyone knows is important for the general community, and the quality of our code. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Disk IO performance
On Mon, Nov 29, 2010 at 12:09 PM, Larry Garfield la...@garfieldtech.com wrote: There are many things that everybody knows about optimizing PHP code. One of them is that one of the most expensive parts of the process is loading code off of disk and compiling it, which is why opcode caches are such a bit performance boost. The corollary to that, of course, is that more files = more IO and therefore more of a performance hit. I'd just organise them how you think makes most sense and then optimize if you run into issues. Kind regards Andrew M -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Disk IO performance
Larry Garfield wrote: There are many things that everybody knows about optimizing PHP code. One of them is that one of the most expensive parts of the process is loading code off of disk and compiling it, which is why opcode caches are such a bit performance boost. The corollary to that, of course, is that more files = more IO and therefore more of a performance hit. [snip] So... does anyone have any actual, hard data here? I don't mean I think or in my experience. I am looking for hard benchmarks, profiling, or writeups of how OS (Linux specifically if it matters) file caching works in 2010, not in 1998. The principle hasn't changed since the 50s - read the file into memory, and keep it there (and keep reading it from there) as long as it isn't written to. The implementation has changed many times over, but it's not something we as regular application programmers ought to be much converned with. Leave it to the smart operating system. -- Per Jessen, Zürich (1.6°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
