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