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