Hi:
On 19 Apr 2011, at 09:18, Stas Malyshev wrote:
> 2. Traits - I remember there was some unfinished business there?
I am not aware of anything that could not be fixed before an alpha release.
However, I would really appreciate if the community could commit to some
release procedure and schedu
2011/4/20 Johannes Schlüter :
>
>
> On 04/20/11 04:18 PM, Dave Ingram wrote:
>>
>> On 04/19/11 15:44, Michael Morris wrote:
>>>
>>> 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
>>> t
On 20 April 2011 15:18, Dave Ingram wrote:
> On 04/19/11 15:44, Michael Morris wrote:
>> 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.
> Just m
On 04/20/11 04:18 PM, Dave Ingram wrote:
On 04/19/11 15:44, Michael Morris wrote:
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.
Just my 0.02 as
On 04/19/11 15:44, Michael Morris wrote:
> 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.
Just my 0.02 as a user, but it strikes me that watch() co
On 2011-04-20, Michael Morris 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
On 20.04.2011 14:24, Johannes Schlüter wrote:
>
>
> On 04/20/11 02:05 PM, Michael Morris wrote:
>> 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 s
On 04/20/11 02:05 PM, Michael Morris wrote:
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
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 a
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
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 'va
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.
Tho
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: ht
Hi!
Is there any thought that we might stop throwing things into trunk
soon and start thinking about some sort of release?
Definitely yes. We have some TODO list for that but I think time has
arrived to get it going. The most major things:
1. Scalar typing. I think we need to do a feature b
> -Original Message-
> From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf
> Of Adam Harvey
> Sent: Monday, April 18, 2011 8:26 AM
> To: internals Mailing List
>
> Is there any thought that we might stop throwing things into trunk soon and
> start thinking about some s
2011/4/19 Ferenc Kovacs :
> 2011/4/18 Johannes Schlüter
>> Only thing for trunk to be done besides stabilization and such is
>> agreeing on the type hint stuff (and if we can't agree at least agree to
>> disagree for the moment and get the release out of the door). Currently
>> we still have the l
2011/4/18 Johannes Schlüter
> +1
>
> Only thing for trunk to be done besides stabilization and such is
> agreeing on the type hint stuff (and if we can't agree at least agree to
> disagree for the moment and get the release out of the door). Currently
> we still have the language extension wh
+1
Only thing for trunk to be done besides stabilization and such is
agreeing on the type hint stuff (and if we can't agree at least agree to
disagree for the moment and get the release out of the door). Currently
we still have the language extension which looks like another syntax but
does no
On 17 April 2011 07:17, Philip Olson wrote:
> 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.
As much as I like this idea — and I really, genuinely,
enthusiasti
n; Moriyoshi Koizumi; Christopher Jones; internals Mailing List
> Subject: Re: [PHP-DEV] RFC: built-in web server in CLI.
>
> On 17 April 2011 15:51, Mikael Fernandus S wrote:
> > As a non core dev, I would like to say that the patches are so handy
> > and this feature will
On 17 April 2011 15:51, Mikael Fernandus S wrote:
> As a non core dev, I would like to say that the patches are so handy
> and this feature will be so helpful in portable php development
> scenarios.
> +1 on this and hoping it will make into the main branch pretty soon.
>
> Similar with others, my
As a non core dev, I would like to say that the patches are so handy
and this feature will be so helpful in portable php development
scenarios.
+1 on this and hoping it will make into the main branch pretty soon.
Similar with others, my suggestion is to put the docroot and router
script as parts o
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
- P
On Fri, Mar 4, 2011 at 11:17 AM, Christopher Jones
wrote:
>
>
> On 03/02/2011 12:55 PM, Moriyoshi Koizumi wrote:
>>
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers. That would be handy for
On 03/02/2011 12:55 PM, Moriyoshi Koizumi wrote:
Hi,
Just to let you know that I wrote a RFC about built-in web server
feature with which PHP can serve contents without a help of web
servers. That would be handy for development purpose.
If interested, have a look at http://wiki.php.net/rfc/b
Derick Rethans wrote:
In short, if you need to configure it more, it'd be better off
> installing Apache to do the right job. I would like to cover just a
> marginal part of the developer needs with this.
I like it being small and simple as well. Sometimes "forcing" people to
use one method a
On Thu, 3 Mar 2011, Moriyoshi Koizumi wrote:
> In short, if you need to configure it more, it'd be better off
> installing Apache to do the right job. I would like to cover just a
> marginal part of the developer needs with this.
I like it being small and simple as well. Sometimes "forcing" peop
Hi,
2011/3/3 Ángel González :
> Moriyoshi Koizumi wrote:
>>> Regarding the patch (https://gist.github.com/835698):
>>> I don't see a switch to disable the internal parse on configure.
>> I don't see any obvious reason it should be able to be turned off
>> through the build option. The only proble
Hi,
On Thu, Mar 3, 2011 at 3:35 PM, Alexey Zakhlestin wrote:
> On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers. That would be ha
Moriyoshi Koizumi wrote:
>> Regarding the patch (https://gist.github.com/835698):
>> I don't see a switch to disable the internal parse on configure.
> I don't see any obvious reason it should be able to be turned off
> through the build option. The only problem is binary size increase,
> which I
On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi wrote:
> Hi,
>
> Just to let you know that I wrote a RFC about built-in web server
> feature with which PHP can serve contents without a help of web
> servers. That would be handy for development purpose.
>
> If interested, have a look at http://
2011/3/3 Ángel González :
> Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers. That would be handy for development purpose.
>>
>> If interested, have a look at http:/
Moriyoshi Koizumi wrote:
> Hi,
>
> Just to let you know that I wrote a RFC about built-in web server
> feature with which PHP can serve contents without a help of web
> servers. That would be handy for development purpose.
>
> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver
On Wed, Mar 2, 2011 at 9:59 PM, Rasmus Lerdorf wrote:
> On 3/2/11 12:55 PM, Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers. That would be handy for development pu
On 3/2/11 12:55 PM, Moriyoshi Koizumi wrote:
> Hi,
>
> Just to let you know that I wrote a RFC about built-in web server
> feature with which PHP can serve contents without a help of web
> servers. That would be handy for development purpose.
>
> If interested, have a look at http://wiki.php.net
35 matches
Mail list logo
