On 2011-04-20, Michael Morris <dmgx.mich...@gmail.com> wrote: > --e0cb4e43cce199248e04a15872c6 > Content-Type: text/plain; charset=ISO-8859-1 > > 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.
I'm going to correct one of your assumptions here, which is "or they write it to a file." Zend_Log has an adapter-based approach to log writers. How the writer performs its task is up to the developer. We have writers that write to web services and databases. Our "file" writer is actually labelled "Stream", because it uses streams. This means you can use "php://stdout" to write to. Additionally, you can have many writers attached to the logger. So, you could have one writing to a file, and another to STDOUT. This is all configurable via a factory. And ZF's solution isn't unique; I've seen other logging solutions that do similarly. My point is: don't dismiss userland solutions out-of-hand; they may offer flexibility that a language-based solution cannot provide. > 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. As I noted above, you can open a stream to php://stdout. If it's unavailable, the text is basically discarded. > 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 >> >> > > --e0cb4e43cce199248e04a15872c6-- -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
