Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=AkDL/ggAu3YGHLOLn10itNAzn6APjs0dSdHoGgiHxKg3ZJO4agODtjF+nT5OnIL6la
         P9024ySBxWXrOUwFJMWiSOs4vsUj7wpRyx6NYKZa1jjzSmFr67obhfZZRC21EQrfsePO
         uukPf5UlJOsLrcZ6PkXBIzyPuFFxRbntVonk0=
MIME-Version: 1.0
In-Reply-To: <4DAE44FA.6020305@gmail.com>
References: <AANLkTinAt4ToUv-FtOeSjbw4Db9iFitE7VvRNZF8yNAc@mail.gmail.com>
	<4D704BA5.5080402@oracle.com>
	<AANLkTimUOQcVT-M6ttba1n7vYOjdUKqf+ntevt=8mywn@mail.gmail.com>
	<D58E8C87-60CC-44C6-9114-010A3B849B8B@roshambo.org>
	<14.AE.01409.86D7DAD4@pb1.pair.com>
	<BANLkTinb3dnCuqgec67pPT6ajuYZyhC=5g@mail.gmail.com>
	<BANLkTi=+VDLjd25CYMNasXbmHufFZnGbFA@mail.gmail.com>
	<4DAE44FA.6020305@gmail.com>
Date: Wed, 20 Apr 2011 08:05:58 -0400
Message-ID: <BANLkTi=o0MgJYAEPYyzghPjo5hmY_zkZzg@mail.gmail.com>
To: David Muir <davidkmuir@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e0cb4e43cce199248e04a15872c6
Subject: Re: [PHP-DEV] RFC: built-in web server in CLI.
From: dmgx.michael@gmail.com (Michael Morris)

--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.

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 <davidkmuir@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.michael@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 <mike@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--