Hello,
for one of my project the profiler doesn't work properly; I've this error:



at line 308 I've this:
$template = preg_replace('/<%([a-zA-Z_0-9\-]*)%>/e', "(array_key_exists('\\1', \$this->__placeholders) ? \$this->__placeholders['\\1'] : '')", $template);

After the popup I can see the result of the profiling but without the line 308 - may be it's some problem with the evaluation of this line.

DBG works properly with this project - the only thing not working is the profiler. I had the same problem with previous versions of phped. Current one is 5.0.1 build 5029 - DBG v3.2.3 - php 4.4.1 (on windows)

Could you help me please?

THank you!

It corresponds to php code that is evaluated (executed) by preg_replace() function. Since it has no physical file, it can't be mapped and may cause mapping errors.
I'd recommend you just ignore the message or use pcre functions that do never run eval() internally and work a bit faster (IMHO).

Hi dmitri, thank you for the response; may be you could try to avoid this kind of alerts

About pcre functions: preg_* are pcre functions; aren't? standard php regexp are ereg, eregi, etc

Thank you!

Yes, the preg_*() function are PCRE; the erg*() functions are POSIX. Both are integral parts of PHP; however, the latter are going away in PHP 6, at least as a built-in component.

yes I know the preg_*() function are PCRE; the erg*() functions are POSIX.

I said that because dmitri suggested to use "pcre functions that do never run eval() internally and work a bit faster" but as shown in my example I already use pcre functions (you can see preg_replace) and I still have the alert from phped

Dmitri can correct me if I'm wrong, but I believe he meant don't use PCRE functions that must call eval(). Put more directly, avoid the /e modifier with preg_replace() when you can, because that causes the parser to call eval() on the replacement string with every replacement iteration, which slows things down. Instead, you might try calling preg_replace_callback(), which allows the PHP engine to work with optimized code (unlike eval()).

As to your original error, I agree it'd be nice if it was more friendly. I run into it a lot trying to get expressions with strings passed in as a string to assert(), and the first time it happened, it left me quite confused for a bit.

Sure, all regexps like /whatever/e are executed with eval(). That's what /e flag stands for. I'm sorry for the misleading answer I posted before.
Regarding the mapping error that profiler shows in this case, I don't think that it can be fixed easily. Hopefully will be done in the next major version