Hi List!
DEBUG_TIMING and the strange order of function
declaraction inside that block is related to my testing
harness for the SQL Parser
OK.
["trigger_error" problem]
This is a problem actually. I don't want to
terminate the
running of the page just because my SQL Parser can't
handle something in the query. I wanted to just print out
a message as to why my parser failed and continue
execution of the page contents.
OK, the we may think about a way to emulate it under
PHP3.
["print_r" problem]
I've changed that to just return the array for now,
and I'll
print it out from my test harness instead.
Fine.
["gzcompress" and "gzcompress" problem]
Just dumping the data base64 encoded got really big, so
I
was just running it thru gzcompress before doing the
base64 encoding.
OK but but should only do this if the "gzcompress"
function is usable ie
if (PMA_PHP_INT_VERSION >= 40001 && @function_exists('gzcompress'))
{
$encodedstr = nl2br(chunk_split(base64_encode(gzcompress($debugstr,
9))));
} else {
$encodedstr = nl2br(chunk_split(base64_encode($debugstr, 9)));
}
The linux kernel has a 'BUG()' call. For some
of our
PMA code, a similar thing would actually be a
very useful function call.
Very interesting idea :)
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif