Those userland solutions (I've written a few myself) send the output as part of the html file that is being composed, or they write it to a file which you then later open up. Which is fine.
This takes advantage of the fact that this CLI client, which will *not* be running as a daemon, will have an open terminal window for it for as long as it persists until the process is stopped with CTRL-C. Sending output to that terminal window would be *very* useful in my opinion, hence the call for trace. Essentially, trace is "echo" to that terminal window, or "print_r" to that window if it is given an object or array. The userland solutions you mention can later be enhanced to take advantage of this trace function when they are running in the CLI webserver environment if their authors so choose. So can this be done now? Yes and no - Yes in the sense that, with a little creative working around, we can get the debug data. No in that the proposed trace statement has two key properties the userland solutions do not and CANNOT have: 1) It sends to the CLI webserver terminal if one exists. 2) If one does not exist the statement is discarded like comment text. On Tue, Apr 19, 2011 at 10:29 PM, David Muir <davidkm...@gmail.com> wrote: > I'm not sure if this is needed when there are already solutions for this. > eg, syslog, error_log, or other userland solutions like Zend_Log, > sfLogger, etc. > > Cheers, > David > > On 19/04/11 23:44, Michael Morris wrote: > > Pardon me for following up my own post, but there is room for a range of > > functions here other than trace that could send their output to the > command > > line where the server was started. > > > > watch ($var) -> $var is sent to the console on the line this statement is > > made with the statment "now watching 'var'.. init value "x", and then > each > > time it changes it is updated in the console. > > > > traceStack() -> as trace, but the current stack is reported. > > traceAll() Return all variables in local scope and the current stack. > > stop() Halt execution as die or exit, unlike them it's arguments are sent > to > > console instead of browser. > > > > On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris <dmgx.mich...@gmail.com > >wrote: > > > >> Since the goal of this is debugging might I suggest borrowing a > statement > >> from the Adobe Flash environment: trace. > >> > >> Trace sends output to the debug console. If given a variable it would > >> format it as print_r currently does. When encountered by PHP in other > modes > >> it would be silently ignored. > >> > >> Thoughts? > >> > >> On Tue, Apr 19, 2011 at 8:17 AM, Michael Wallner <m...@php.net> wrote: > >> > >>> On 04/17/2011 01:17 AM, Philip Olson wrote: > >>> > >>>> Greetings Moriyoshi and all, > >>>> > >>>> Are people still thinking about this? And how about applying the > >>>> current/revised patch to trunk thus making it easier to play with and > >>>> break, but not freeze its features/API yet. > >>>> > >>>> Also the wiki is up again so: > >>>> > >>>> - RFC: https://wiki.php.net/rfc/builtinwebserver > >>>> - Patch is here: http://gist.github.com/835698 > >>>> > >>> The php_http_* "namespace" is actually already used by pecl_http? > >>> > >>> Regards, > >>> Mike > >>> > >>> > >>> -- > >>> PHP Internals - PHP Runtime Development Mailing List > >>> To unsubscribe, visit: http://www.php.net/unsub.php > >>> > >>> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
