RFC: phpdbg

I'm probably missing some context here, maybe you could explain how
phpdbg
differs from something like xdebug? I mean, xdebug seems to be the
de-facto
debugging extension for PHP and has been for a long time, but we're not
bundling it. Why should we bundle phpdbg instead?

    This is not an extension, it is a SAPI module. The build system

does

not support external SAPI modules, the implementation requires Zend API
which is not exported (or wasn't, has since been patched).

That still does not answer the question, though?!

My question is very similar. Why not just bundle xdebug?

I'm probably missing some context here, maybe you could explain how phpdbg
differs from something like xdebug? I mean, xdebug seems to be the
de-facto
debugging extension for PHP and has been for a long time, but we're not
bundling it. Why should we bundle phpdbg instead?

     This is not an extension, it is a SAPI module. The build system does

not support external SAPI modules, the implementation requires Zend API
which is not exported (or wasn't, has since been patched).

That still does not answer the question, though?!

Yes, it does.

xdebug has a reasonable route to deployment already, it, and none of
it's users, benefit at all from xdebug being bundled.

This is not the same, it can be deployed outside of the source tree but
it's much harder, for most people, and for some impossible.

I was happy writing code, getting a few functions exported and deploying
to those people with the ability to build ...

I don't much care for anything but writing the code, and will go back to
that now ...

I'm probably missing some context here, maybe you could explain how phpdbg
differs from something like xdebug? I mean, xdebug seems to be the
de-facto
debugging extension for PHP and has been for a long time, but we're not
bundling it. Why should we bundle phpdbg instead?
This is not an extension, it is a SAPI module. The build system does
not support external SAPI modules, the implementation requires Zend API
which is not exported (or wasn't, has since been patched).
That still does not answer the question, though?!
Nikita asked two questions. Joe answered the first. My reading of
what he says, plus following the links to his write up on
http://phpdbg.com, is because phpdbg is a SAPI -- as far as I can see
esentially a debug variant of the CLI SAPI -- you can use it very much
the same way that you can debug perl scripts with the "perl -d" switch.

This is functionality that I for one REALLY miss with PHP. Maybe its
just me, but I've tried using xdebug without modifying the source, and I
find it very difficult to configure for anything other than getting
smart tracebacks on errors. Also xdebug being an extension, you have
to be careful about load order when debugging other extensions. I
usually give up using xdebug and add (temporary) diagnostics to the PHP
source code.

As to Nikita's second Q: why should we bundle phpdbg instead of xdebug?
I think that an average PHP developer would find a CLI debug interface
that could be enabled through a command line switch a valuable addition
to the PHP development toolset. This utility argument was valid for
the -S option and the CLI webserver mode, so why not apply this same
argument here?

Morning,

     This is not an extension, it is a SAPI module. The build system

does not support external SAPI modules, the implementation requires Zend
API which is not exported (or wasn't, has since been patched).

Independently from phpdbg, is there any particular (technical) reason that
prevents (zend?) extensions from registering SAPIs? Could we add something
for that to work?

Nikita

(Sorry niki, you will get this twice ...)

My head gets stuck in a loop when trying to think about it ... for a
zend extension or, certainly, an extension, to be able to do anything at
all, zend has to be initialized, it probably can work in some cases, but
if the purpose of the sapi module is to direct how zend behaves then it
won't work, I don't think ...

Building against 5.6+ is not a problem anyway, we could maybe even patch
embed and build against that for phpdbg in particular, but the problem
isn't so much how difficult it is to write a makefile but how difficult
it is to deploy any SAPI module apart from the sources. Nobody using
windows does their own builds, for a start, although you can distribute
binaries if you are a master of VC, which I'm not. Even on unix nobody
builds from source, nobody builds the embed library, it's not enough to
have a working build process because that doesn't get you into the
repositories for the major distributions.

I certainly would like to see improvements made such that in the future
it is easier to deploy SAPI modules, it's not useful for phpdbg, but
would be a very welcome change, for me ...

Cheers
Joe

Independently from phpdbg, is there any particular (technical) reason that
prevents (zend?) extensions from registering SAPIs? Could we add something
for that to work?

Nikita, if you think about it the SAPI contains main() -- or the
respective shared library master entry point, and acts as the calling /
callback framework for the Zend environment. To make the SAPI an
extension would require inverting this PHP Zend architecture so that
there is some sort of general minimal wrapper which can then layer in an
additional personality by loading in some shared library from some
context. However, this wouldn't be a Zend or PHP extension as we know
it. This would involve a lot of work.

Thinking off the top of my head, what we could possibly do would be to
hook some of the standard entries in the CLI SAPI so that a SAPI-aware
extension could insert itself into this chain and modify the behaviour
of the standard CLI (or potentially other) SAPIs. This approach could
allow phpdbg to be a Zend Extension "skin" on the standard CLI.

Regards Terry

Independently from phpdbg, is there any particular (technical) reason that
prevents (zend?) extensions from registering SAPIs? Could we add something
for that to work?

yes - simplyas the SAPI is the thing starting PHP. Etensions are loaded
after ... what is possible is using embed SAPI to get a PHP lib and link
that to some SAPI.

phpsrc$ ./configure --enable-embed && make && make install
sapi$ gcc -osuper_php -lphp some_sapi.c

The extra stuff in embed can easily be ignored, the generated libphp.so
(or liphp.a when using --enable-embed=static) offers all symbols needed.

johannes