Re: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
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 schedule. For me it is currently really hard to see what the next steps are. If a release manager gives me a deadline, I am sure that all the traits-related things can be finished. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 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. error_log() output should go there by default. (didn't check the patch) you can route everything there. I don't think it's good to add tons of extra functions for that. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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
Re: [PHP-DEV] RFC: built-in web server in CLI.
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() could be a handy addition that would be difficult and/or extremely painful to do in userland. Dave -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 a user, but it strikes me that watch() could be a handy addition that would be difficult and/or extremely painful to do in userland. ... but this can be relatively easily be done in a debug extension and that's where this belongs. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On 20 April 2011 15:18, Dave Ingram d...@dmi.me.uk 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 a user, but it strikes me that watch() could be a handy addition that would be difficult and/or extremely painful to do in userland. Dave Being able to watch($var [, ...]), unwatch($var [, ...]) and trace([bool $start = true]) without a debugger in userland ... Just like you can overload session handling logic by using session_set_save_handler(), would something like ... bool debugging_set_handler(callback $watch, callback $unwatch, callback $trace); be of use? -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
2011/4/20 Johannes Schlüter johan...@schlueters.de: 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 a user, but it strikes me that watch() could be a handy addition that would be difficult and/or extremely painful to do in userland. ... but this can be relatively easily be done in a debug extension and that's where this belongs. johannes If the extension could allow for userland interpretation of the debug events ... then I think that's the best of all worlds. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
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 branch from it and remove it from trunk. If nobody would take it I can do it though it probably will take me a couple of week(end)s at least looking at my schedule. 2. Traits - I remember there was some unfinished business there? There's also a number of smaller improvements that we may want in/out decisions on, and I'm sure people have some TODO items for it, so let's put them here: https://wiki.php.net/todo/php54 -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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
Re: [PHP-DEV] RFC: built-in web server in CLI.
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
Re: [PHP-DEV] RFC: built-in web server in CLI.
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.comwrote: 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
Re: [PHP-DEV] RFC: built-in web server in CLI.
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.comwrote: 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
[PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
On 17 April 2011 07:17, Philip Olson phi...@roshambo.org 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, enthusiastically* do — allow me to open the can of worms and repeat a question I've asked periodically on IRC and IRL (with varying levels of directness) over the last few months: Is there any thought that we might stop throwing things into trunk soon and start thinking about some sort of release? 5.3.0 came out in June 2009. Even if we start the alpha process now, there's no chance trunk is going to hit stable until the last few months of the year, so we're looking at over two years between minor releases, which is about as long as I'd be comfortable leaving it — not just for any PR reason, but because there's some genuinely good stuff in trunk that I think deserves to see the light of day. I mean, if people want to continue experimenting, that's great, but should we be factoring this into the thought process, at least? There's nothing stopping a 5.4 branch being created earlier than has been traditional (say, alpha 1 or beta 1) and letting development continue on trunk. In effect, we'd simply be reverting to the three branch model that's existed for most of the last few years. Sorry to hijack the thread, but I think the question needs to be asked. Anviliciously yours, Adam * You can insert more adverbs if you like. I am very +1 on this feature. I use the equivalent feature provided by Django for development all the time, and it's amazingly handy. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
+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 nothing in the tree. ('function foo(int $a) { var_dump($a); }
foo(string);' is valid code printing string(6) string)
johannes
On Mon, 2011-04-18 at 23:25 +0800, Adam Harvey wrote:
On 17 April 2011 07:17, Philip Olson phi...@roshambo.org 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,
enthusiastically* do — allow me to open the can of worms and repeat a
question I've asked periodically on IRC and IRL (with varying levels
of directness) over the last few months:
Is there any thought that we might stop throwing things into trunk
soon and start thinking about some sort of release?
5.3.0 came out in June 2009. Even if we start the alpha process now,
there's no chance trunk is going to hit stable until the last few
months of the year, so we're looking at over two years between minor
releases, which is about as long as I'd be comfortable leaving it —
not just for any PR reason, but because there's some genuinely good
stuff in trunk that I think deserves to see the light of day.
I mean, if people want to continue experimenting, that's great, but
should we be factoring this into the thought process, at least?
There's nothing stopping a 5.4 branch being created earlier than has
been traditional (say, alpha 1 or beta 1) and letting development
continue on trunk. In effect, we'd simply be reverting to the three
branch model that's existed for most of the last few years.
Sorry to hijack the thread, but I think the question needs to be asked.
Anviliciously yours,
Adam
* You can insert more adverbs if you like. I am very +1 on this
feature. I use the equivalent feature provided by Django for
development all the time, and it's amazingly handy.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
2011/4/18 Johannes Schlüter johan...@schlueters.de
+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 nothing in the tree. ('function foo(int $a) { var_dump($a); }
foo(string);' is valid code printing string(6) string)
johannes
btw. whats up with the
https://wiki.php.net/rfc/releaseprocesshttps://wiki.php.net/rfc/releaseprocess?s[]=releases[]=process
?
it's been a while since Pierre said that We are almost ready to go with
it, a matter of weeks. I fear that a major release is something we
are not able to deal with right now.
I think we can agree that this one will be a minor version, and as such, it
would be a safe bet to go with the 5.4.
the RM(s) should be elected(or did a formal election happened since the last
time?) and we could freeze the trunk (or branch the 5.4) and start sorting
out, that what needs to worked on, or removed for the release.
Tyrael
Re: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
2011/4/19 Ferenc Kovacs i...@tyrael.hu:
2011/4/18 Johannes Schlüter johan...@schlueters.de
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 nothing in the tree. ('function foo(int $a) { var_dump($a); }
foo(string);' is valid code printing string(6) string)
In theory, I want scalar type hints, but if we're still deadlocked on
that (and I suspect we still will be if it goes to a vote), I'd
happily see it backed out and sacrifice it to get a 5.4 release.
btw. whats up with the https://wiki.php.net/rfc/releaseprocess ?
Seems to have fallen through the cracks, but I still think it's a good idea.
I think we can agree that this one will be a minor version, and as such, it
would be a safe bet to go with the 5.4.
+1.
the RM(s) should be elected(or did a formal election happened since the last
time?) and we could freeze the trunk (or branch the 5.4) and start sorting
out, that what needs to worked on, or removed for the release.
+1.
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)
-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 sort of release? 5.3.0 came out in June 2009. Even if we start the alpha process now, there's no chance trunk is going to hit stable until the last few months of the year, so we're looking at over two years between minor releases, which is about as long as I'd be comfortable leaving it — not just for any PR reason, but because there's some genuinely good stuff in trunk that I think deserves to see the light of day. I completely agree. The current PHP 5.4 source tree (a.k.a. trunk) already has *major* enhancements. Just look at the NEWS file. I think it's a mistake we don't start a release cycle. If we try and get too much into this release it just won't happen. The typehint stuff which has no consensus should be reverted and we should start pushing forward with a release. Things which people wanted to get done and didn’t (e.g. Pierre asked for another 3-4 weeks to do some more Windows work (about 4-5 months ago which I don’t know if ever happened) should not slow down a release and be marked as nice-to-have – if it doesn’t make the train it can wait for the next version; if they do, great. Btw, just performance and memory use itself is a good enough reason to push a minor release and every day that goes by where we prevent people from getting their hands on it is a day we're warming up the planet faster. This is between 16-20% faster and on average 30% lower memory usage (the latter is the more exciting change thanks to a lot of memory optimization we did; with a release cycle started and people testing/comparing we may be able to squeeze even more out of it). I’d also like to see some of the work around making mbstring a configurable option out sooner rather than later… My 2 cents. We can work closely with an RM to move things forward and ensure we push out a lot of the really good stuff that was done. Andi
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 of the options. An option to specify max number of connections would be nice but perhaps it can be in a future wishlist. Regards, Mike On Sun, Apr 17, 2011 at 8:17 AM, Philip Olson phi...@roshambo.org 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 Regards, Philip -- 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
Re: [PHP-DEV] RFC: built-in web server in CLI.
On 17 April 2011 15:51, Mikael Fernandus S mika...@gmail.com 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 suggestion is to put the docroot and router script as parts of the options. An option to specify max number of connections would be nice but perhaps it can be in a future wishlist. Regards, Mike On Sun, Apr 17, 2011 at 8:17 AM, Philip Olson phi...@roshambo.org 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 Regards, Philip What would happen if you could combine these patches with the Win32Service pecl extension ... could you not have a real PHP orientated web server running which was capable of starting up and shutting down with the OS. Hey! Who would need IIS or Apache then! (OK. Just kidding). -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: built-in web server in CLI.
I really like the idea. Just to be clear though I'd change: Server is listening on localhost:8000... Press CTRL-C to quit. To something like: PHP Development Server is listening on localhost:8000... Press CTRL-C to quit. I think that makes it very clear this is for development and enhancements will be focused on ensuring the dev environment works and not trying to make this into a mini Apache. Andi -Original Message- From: Richard Quadling [mailto:rquadl...@gmail.com] Sent: Sunday, April 17, 2011 1:29 PM To: Mikael Fernandus S Cc: Philip Olson; 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 mika...@gmail.com 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 suggestion is to put the docroot and router script as parts of the options. An option to specify max number of connections would be nice but perhaps it can be in a future wishlist. Regards, Mike On Sun, Apr 17, 2011 at 8:17 AM, Philip Olson phi...@roshambo.org 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 Regards, Philip What would happen if you could combine these patches with the Win32Service pecl extension ... could you not have a real PHP orientated web server running which was capable of starting up and shutting down with the OS. Hey! Who would need IIS or Apache then! (OK. Just kidding). -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 guess is quite subtle. Seems sufficiently different from normal cli. The patch looks messy as it splits main in two functions, so it gets hard to follow, but is probably good overall. Assuming you are mentioning about the option parsing portion of the code, yes, it's a bit messy, but I had to do so because runtime initialization procedure is very different from the ordinary CLI. Wasn't critizising you. It's a limitation of unified diffs, which can't say move this bunch of code 25 lines down. A bit hard to follow, but aparently good. The change from php_printf to printf in line 3988 looks wrong. php_printf() eventually redirects the output to sapi_module.ub_write(), which should only be available after proper SAPI initialization. The changed part can be reached before the initialization and it absolutely makes no sense to use php_printf() when you simply want to print a message text before the script starts in the console. Fair enough. Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? cli-win32 version of PHP doesn't have an associated console and is supposed to use to create applications without console interactions (i.e. GUI). So, It doesn't make sense to enable this feature for it. With the embedded web server, the interaction would be done via the browser. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
Hi, On Thu, Mar 3, 2011 at 3:35 PM, Alexey Zakhlestin indey...@gmail.com wrote: On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi m...@mozo.jp 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 . Interesting, indeed. I noticed, that you hardcode mimetypes and index_files. Mimetypes can probably be obtained from the system — we even had some extension doing that. And index_files should be configurable, because there are some situations when people don't want any mime-types at all. Also, it would be good to be able to configure which files are actually parsed by php, not just served. Currently, these are only .php files We coundn't always count on the existence of mime.types, which is likely installed with Apache that is uncalled for. Neither do I see any good reason to make index files configurable because I have hardly seen such a peculiar setting for several years that uses file names other than index.html or index.php for index files. I used to use index.htm for technical reasons though. 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. Regards, Moriyoshi -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
Hi, 2011/3/3 Ángel González keis...@gmail.com: 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 guess is quite subtle. Seems sufficiently different from normal cli. I've seen a number of people arguing on the same, but I'd rather have them both in for the sake of simplicity. As discussed when the CLI version of PHP was born, multiple PHP binaries actually have confused the users to a certain degree. The patch looks messy as it splits main in two functions, so it gets hard to follow, but is probably good overall. Assuming you are mentioning about the option parsing portion of the code, yes, it's a bit messy, but I had to do so because runtime initialization procedure is very different from the ordinary CLI. Wasn't critizising you. It's a limitation of unified diffs, which can't say move this bunch of code 25 lines down. A bit hard to follow, but aparently good. I would have put a whitespace-ignoring diff as well ;-) Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? cli-win32 version of PHP doesn't have an associated console and is supposed to use to create applications without console interactions (i.e. GUI). So, It doesn't make sense to enable this feature for it. With the embedded web server, the interaction would be done via the browser. It is not intended to be daemonized at all since it's just a development web server. To do more, Apache should work great then. Regards, Moriyoshi -- 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
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 people to use one method actually makes things easier to use. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 actually makes things easier to use. AND a lot easier to debug when people are having problems getting something working ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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/builtinwebserver . Regards, Moriyoshi To allow for future changes, all options should require flags. For example, php -S localhost:8000 -d docroot instead of the currently proposed php -S localhost:8000 docroot Have you thought about integration with run-tests.php? -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On Fri, Mar 4, 2011 at 11:17 AM, Christopher Jones christopher.jo...@oracle.com 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 development purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Regards, Moriyoshi To allow for future changes, all options should require flags. For example, php -S localhost:8000 -d docroot instead of the currently proposed php -S localhost:8000 docroot That might make sense. I am thinking that being unable to specify a document root with a router script is a bit inconsistent. Have you thought about integration with run-tests.php? Not in mind yet, but if it's better than CGI. Moriyoshi -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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/rfc/builtinwebserver . I like it. Need to go through it very carefully and look for security-related issues though. Make sure all memory handling is safe. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On Wed, Mar 2, 2011 at 9:59 PM, Rasmus Lerdorf ras...@lerdorf.com 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 purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . I like it. Need to go through it very carefully and look for security-related issues though. Make sure all memory handling is safe. Same here, very handy. I would not worry too much about security related issues as such builtin server should really be used for development purposes only (yes, users do bad things even if we say to do not it :). -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
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 . Regards, Moriyoshi I like the idea. Regarding the patch (https://gist.github.com/835698): I don't see a switch to disable the internal parse on configure. I'd expect the files to be on its own folder inside sapi, even being able to bundle them in a single binary. Why is this needed on WIndows? + ADD_FLAG(LIBS_CLI, ws2_32.lib); Surely php will already link with the sockets library for its own functions. The http parser code seems copied from https://github.com/ry/http-parser and it may not be a good idea to modify it downstream, but it seems to do more things than strictly needed by php (eg. there are more methods than those a php server would take use). It also seems to be a hand-coded lexer, so that's much more verbose than a set of rules. The patch looks messy as it splits main in two functions, so it gets hard to follow, but is probably good overall. The change from php_printf to printf in line 3988 looks wrong. Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
2011/3/3 Ángel González keis...@gmail.com: 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 . Regards, Moriyoshi I like the idea. 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 guess is quite subtle. I'd expect the files to be on its own folder inside sapi, even being able to bundle them in a single binary. Why is this needed on WIndows? + ADD_FLAG(LIBS_CLI, ws2_32.lib); Surely php will already link with the sockets library for its own functions. Of course the objects that directly involves generation of php.exe depend on WinSock functions. Other socket related portion is inside php5.dll (php5ts.dll) whose imported symbols cannot be referred to unlike ELF shared objects. The http parser code seems copied from https://github.com/ry/http-parser and it may not be a good idea to modify it downstream, but it seems to do more things than strictly needed by php (eg. there are more methods than those a php server would take use). It also seems to be a hand-coded lexer, so that's much more verbose than a set of rules. Do we really have to look into the parser right now? I don't think we have to limit the methods that the server can accept since there is no reason limiting it though the server can deal with, I don't find it a problem for it to be hand-coded either. The patch looks messy as it splits main in two functions, so it gets hard to follow, but is probably good overall. Assuming you are mentioning about the option parsing portion of the code, yes, it's a bit messy, but I had to do so because runtime initialization procedure is very different from the ordinary CLI. The change from php_printf to printf in line 3988 looks wrong. php_printf() eventually redirects the output to sapi_module.ub_write(), which should only be available after proper SAPI initialization. The changed part can be reached before the initialization and it absolutely makes no sense to use php_printf() when you simply want to print a message text before the script starts in the console. Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? cli-win32 version of PHP doesn't have an associated console and is supposed to use to create applications without console interactions (i.e. GUI). So, It doesn't make sense to enable this feature for it. Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi m...@mozo.jp 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 . Interesting, indeed. I noticed, that you hardcode mimetypes and index_files. Mimetypes can probably be obtained from the system — we even had some extension doing that. And index_files should be configurable, because there are some situations when people don't want any mime-types at all. Also, it would be good to be able to configure which files are actually parsed by php, not just served. Currently, these are only .php files -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
