<snip> > AM sapi/phpdbg/xml.mdCommit: 2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Author: Bob Weinand bobwei9@hotmail.com Fri, 24 Oct 2014 19:29:50 +0200
Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d
Branches: masterLink: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Log:
Made phpdbg compatible with new engine
Although this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up with a
new XML protocol for debugging.
So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that already
exists? PHPDBG is difficult to use with its odd command line "commands".
And then I haven't even spoken about the pretentious "awesomesauce" on
http://phpdbg.com/ — a domain that's not even under the PHP group's
control.
cheers,
Derick
<snip> > AM sapi/phpdbg/xml.mdCommit: 2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Author: Bob Weinand bobwei9@hotmail.com Fri, 24 Oct 2014 19:29:50 +0200
Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d
Branches: masterLink: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Log:
Made phpdbg compatible with new engineAlthough this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up with a
new XML protocol for debugging.So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that already
exists? PHPDBG is difficult to use with its odd command line "commands".
And then I haven't even spoken about the pretentious "awesomesauce" on
http://phpdbg.com/ — a domain that's not even under the PHP group's
control.cheers,
Derick
Derick,
A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you don't
know how to use it.
This is a strange sort of silence, and does not invite us to
co-operate.
When you invented dbgp there were other protocols in existence, not
sure why we are expected to reuse a protocol. It so happens that the
phpstorm guys working on integration seemed keen on something new. I
don't see the problem in that. If the only reason it exists is for
projects like phpstorm and they are actually going to put time into
trying something new, then why the hell not.
I'm not sure why it matters what kind of language we use on phpdbg.com,
not sure why you think it should be under the control of the php group
either.
If you had wanted to co-operate, you could have spoken to me at that
conference in person, or to any of us in IRC, on any day. You chose to
do what pleased you.
We should be allowed to do the same.
Joe
hi,
Although this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up with a
new XML protocol for debugging.So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that already
exists? PHPDBG is difficult to use with its odd command line "commands".
And then I haven't even spoken about the pretentious "awesomesauce" on
http://phpdbg.com/ — a domain that's not even under the PHP group's
control.cheers,
DerickDerick,
A few weeks ago, I was at a conference where you told a room filledwith hundreds of developers that phpdbg was no good, because you don't
know how to use it.This is a strange sort of silence, and does not invite us toco-operate.
Well, not well played but I do not think arguing back and forth about
that will bring us anywhere. I will just skip any part of this
discussion about this kind of things.
When you invented dbgp there were other protocols in existence, notsure why we are expected to reuse a protocol. It so happens that the
phpstorm guys working on integration seemed keen on something new. I
don't see the problem in that. If the only reason it exists is for
projects like phpstorm and they are actually going to put time into
trying something new, then why the hell not.
While you are right from a principle point of view, I do think it
makes sense to implement something which is already a de facto
standard in the PHP world, well supported by various tools, etc. If
phpdbg would not be in core, I would not care much, as you said, it
would then be an independent project and you can do whatever you wish.
However it is not the case, phpdbg is in the core. Being in core means
it does affect how our users will work, use it, etc. Design decisions
like protocol used to work with external tools should be taken very
carefully. Adding yet another one does not sound very good at a first
glance.
Do you mind to enlighten us about the advantages of this new protocol
over the existing one? Or what are the limitations of the existing one
which lead you to the creation of a phpdbg protocol?
I'm not sure why it matters what kind of language we use on phpdbg.com,not sure why you think it should be under the control of the php group
either.
Well, phpdbg is part of the core. As such it reflects what PHP is,
does or says. I do not have a problem with anything I have seen on the
project site but this is something to keep in mind.
If you had wanted to co-operate, you could have spoken to me at thatconference in person, or to any of us in IRC, on any day. You chose to
do what pleased you.We should be allowed to do the same.
Yes and no, as I wrote earlier in this reply.
Thanks for the great work and let try to sort that out :)
Cheers,
Pierre
hi,
Although this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up with a
new XML protocol for debugging.So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that already
exists? PHPDBG is difficult to use with its odd command line "commands".
And then I haven't even spoken about the pretentious "awesomesauce" on
http://phpdbg.com/ — a domain that's not even under the PHP group's
control.cheers,
DerickDerick,
A few weeks ago, I was at a conference where you told a room filledwith hundreds of developers that phpdbg was no good, because you don't
know how to use it.This is a strange sort of silence, and does not invite us toco-operate.
Well, not well played but I do not think arguing back and forth about
that will bring us anywhere. I will just skip any part of this
discussion about this kind of things.When you invented dbgp there were other protocols in existence, notsure why we are expected to reuse a protocol. It so happens that the
phpstorm guys working on integration seemed keen on something new. I
don't see the problem in that. If the only reason it exists is for
projects like phpstorm and they are actually going to put time into
trying something new, then why the hell not.While you are right from a principle point of view, I do think it
makes sense to implement something which is already a de facto
standard in the PHP world, well supported by various tools, etc. If
phpdbg would not be in core, I would not care much, as you said, it
would then be an independent project and you can do whatever you wish.
However it is not the case, phpdbg is in the core. Being in core means
it does affect how our users will work, use it, etc. Design decisions
like protocol used to work with external tools should be taken very
carefully. Adding yet another one does not sound very good at a first
glance.
Do you mind to enlighten us about the advantages of this new protocol
over the existing one? Or what are the limitations of the existing one
which lead you to the creation of a phpdbg protocol?I'm not sure why it matters what kind of language we use on phpdbg.com,not sure why you think it should be under the control of the php group
either.Well, phpdbg is part of the core. As such it reflects what PHP is,
does or says. I do not have a problem with anything I have seen on the
project site but this is something to keep in mind.If you had wanted to co-operate, you could have spoken to me at thatconference in person, or to any of us in IRC, on any day. You chose to
do what pleased you.We should be allowed to do the same.Yes and no, as I wrote earlier in this reply.
Thanks for the great work and let try to sort that out :)
Cheers,
Pierre
Pierre,
I wasn't involved in the conversations during it's development very
much. You will have to wait for bob or someone from the phpstorm team to
fill in the blanks. Suffice to say that they found a reason to work on a
new protocol, details I don't know.
It had it's own remote protocol when it was merged, but it turned out
to be pretty useless for those people interested in using it remotely.
This is only a development of that original feature.
I of course recognize that we are in some sense representative of the
PHP project, however, we are talking about words like awesomesauce, not
profanity, or anything offensive whatever.
Bob done all the work on this, in record time. It's totally crappy that
he'll wake up today to this nonsense, he should be feeling pleased with
himself. He worked very hard on it.
Cheers
Joe
Pierre,
I wasn't involved in the conversations during it's development verymuch. You will have to wait for bob or someone from the phpstorm team to
fill in the blanks. Suffice to say that they found a reason to work on a
new protocol, details I don't know.It had it's own remote protocol when it was merged, but it turned outto be pretty useless for those people interested in using it remotely.
This is only a development of that original feature. I of course recognize that we are in some sense representative of thePHP project, however, we are talking about words like awesomesauce, not
profanity, or anything offensive whatever.Bob done all the work on this, in record time. It's totally crappy thathe'll wake up today to this nonsense, he should be feeling pleased with
himself. He worked very hard on it.
Cannot agree more. I very much like phpdbg and really appreciate all
the aweome work you guys have put in it. I am only trying to
understand this whole protocol thing, in the most objecitve way :). I
did not know phpstorm was involved either, that makes me feel better
about it. They know very well what is needed and have a very large
experience in this area. I am convinced things will be clear soon :)
--
Pierre
@pierrejoye | http://www.libgd.org
Just a minor question, Derick. If you care about phpdbg, why are you only dropping any comment about it by the time it got into php-src repo? It’s known that all the development currently (except for master, but that just was a merge and then a pure rewrite on top of that merge, nothing related to the protocol) is going on in krakjoe/phpdbg github repo. There was now an xml-protocol branch for three weeks before it got merged into krakjoe/phpdbg#master. You had vast time to notice it and complain before, if you’d really have cared.
To reply to your question: why not use another debugger protocol?
I had first really looked for other protocols, but none really fitted our needs. There was just DBGp which approximated our needs.
At the beginning I had tried to implement a slightly modified variant of DBGp, but it accumulated minor differences here and there… And that then doesn’t make much sense again.
That was the time where we decided to implement our own protocol.
Before you ask, an incomplete list of such differences:
- connecting: phpdbg is the server, not the client (as opposed to what DBGp requires)
- no need for the proxy thing
- breakpoints: we have an opline-wise breaking (I have no idea, but maybe an IDE might want to break before the fcall is done) doesn’t fit into current list of attributes
- It is under some circumstances possible to not be able to provide a full response (e.g. we’ve done a hard interrupt (that means, instant, asynchronous interrupt, even when engine is in control of it)) - DBGp provides no mechanism to handle it
- stdout, stderr commands also don’t really work with phpdbg — it’s always redirect mode
- …
Further, but not the main reason why we didn’t use it, we’d have had to implement another commands lexer, parser and interpreter alongside our current commands. DBGp commands aren’t exactly user-friendly; they’re designed to be used by a machine.
It made the whole implementation a lot easier to not use a fork of DBGp adapted to our needs. (at the time we realized we couldn’t really use DBGp)
So, we’ve introduced a new protocol. I didn’t try to make a protocol compatible with any future debugger; each debugger has a bit his special needs and you cannot suit everyones needs.
Bob
p.s.: And yes, PhpStorm was involved, a huge thanks to them for the precious feedback they’ve given me for the last three weeks.
Am 25.10.2014 um 11:45 schrieb Pierre Joye pierre.php@gmail.com:
Pierre,
I wasn't involved in the conversations during it's development verymuch. You will have to wait for bob or someone from the phpstorm team to
fill in the blanks. Suffice to say that they found a reason to work on a
new protocol, details I don't know.It had it's own remote protocol when it was merged, but it turned outto be pretty useless for those people interested in using it remotely.
This is only a development of that original feature. I of course recognize that we are in some sense representative of thePHP project, however, we are talking about words like awesomesauce, not
profanity, or anything offensive whatever.Bob done all the work on this, in record time. It's totally crappy thathe'll wake up today to this nonsense, he should be feeling pleased with
himself. He worked very hard on it.Cannot agree more. I very much like phpdbg and really appreciate all
the aweome work you guys have put in it. I am only trying to
understand this whole protocol thing, in the most objecitve way :). I
did not know phpstorm was involved either, that makes me feel better
about it. They know very well what is needed and have a very large
experience in this area. I am convinced things will be clear soon :)--
Pierre@pierrejoye | http://www.libgd.org
...
Thanks Bob.
So my question is: Obviously the phpdbg requirements do not map to
DBGp. However, can all of the requirements of DBGp be mapped to the
phpdbg XML?
Going forward does the XML protocol cover everything XDebug needs? Can
we do "DBGp over XML"?
Am 25.10.2014 um 13:25 schrieb Leigh leight@gmail.com:
...
Thanks Bob.
So my question is: Obviously the phpdbg requirements do not map to
DBGp. However, can all of the requirements of DBGp be mapped to the
phpdbg XML?Going forward does the XML protocol cover everything XDebug needs? Can
we do "DBGp over XML“?
We currently also don’t provide e.g. exception breaks (because either no-one of us thought of it or found it useful). There may be already the minor problems in the other direction.
But generally, one could (after adding connection overhead). Though I wouldn’t think of it as a good idea as it’ll break everything which doesn’t support phpdbg, but xdebug.
But it wasn’t primarily intended to be forward compatible with other debuggers.
Bob
...
Thanks Bob.
So my question is: Obviously the phpdbg requirements do not map to
DBGp. However, can all of the requirements of DBGp be mapped to the
phpdbg XML?Going forward does the XML protocol cover everything XDebug needs? Can
we do "DBGp over XML"?
DBGp is XML. This question makes no sense.
cheers,
Derick
Am 25.10.2014 um 13:00 schrieb Weinand Bob:
It’s known that all the development currently is going on in
krakjoe/phpdbg github repo.
Why is that, exactly? I find it weird that something that is shipped
with official releases of PHP is not developed alongside the rest of
PHP.
Am 25.10.2014 um 17:37 schrieb Sebastian Bergmann sebastian@php.net:
Am 25.10.2014 um 13:00 schrieb Weinand Bob:
It’s known that all the development currently is going on in
krakjoe/phpdbg github repo.Why is that, exactly? I find it weird that something that is shipped
with official releases of PHP is not developed alongside the rest of
PHP.
That’s because all the work originated in the krakjoe/phpdbg repo, even before it was pushed to php-src.
Also, it contains code which makes it compatible with PHP 5.4+. If it’d be in the main repo, users with lower PHP versions couldn’t use it at all.
By the way, phpdbg in PHP 7 isn’t handled by that repo anymore, it’s directly in master. But new features will still have to be merged up (except if it are PHP 7-only features) as long as PHP 5 branch has still one active (non-sec-fixes-only) branch.
Bob
Hi!
Just a minor question, Derick. If you care about phpdbg, why are you
only dropping any comment about it by the time it got into php-src
repo? It’s known that all the development currently (except for
master, but that just was a merge and then a pure rewrite on top of
that merge, nothing related to the protocol) is going on in
krakjoe/phpdbg github repo. There was now an xml-protocol branch for
three weeks before it got merged into krakjoe/phpdbg#master. You had
vast time to notice it and complain before, if you’d really have
cared.
I would like to weigh in here. If we're talking about things in PHP core
repo, "we did it somewhere in public repo and nobody complained" is not
a good stance. People do literally hundreds of things around PHP in
public places, but not everything is part of PHP core. phpdbg now is.
That involves not only good parts (by-default acceptance by millions of
PHP users) but some obligations - like proper discussion and
notification. Of course, since master is not stable yet, we have
somewhat relaxed rules there, but even then introducing new debugging
protocol into PHP core seems to be something that warrants some
notification. As a person who spent significant time on implementing and
maintaining one of PHP debugging solutions in the past, I, for example,
would be interested to take a look into what is being checked into core
repo in this regard. However, the first note I see about this happening
is the commit messages. And that takes us back to old and not-so-good
"check in first, discuss later" times. With project of the size of PHP,
it having good process matters no less than having good code.
So saying "we had this branch for whole three weeks before merging it
into PHP repo" is not really saying much.
That said, we are where we are, and I think it would be great if this
would somehow server as a starting point for developing a unified
protocol for debugging PHP. There are a number of good tools for
debugging PHP, and it would be a pity if everybody invented their own
protocols and required to install half-dozen of extensions to be
compatible with all tools doing the same in slightly different way.
We have so many unification efforts with PSR and the spec and so on, I'm
pretty sure we can make a protocol that would be workable for all,
debugging PHP is not exactly rocket surgery and there are not that many
things there that we couldn't find a common ground.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
Just a minor question, Derick. If you care about phpdbg, why are you
only dropping any comment about it by the time it got into php-src
repo? It’s known that all the development currently (except for
master, but that just was a merge and then a pure rewrite on top of
that merge, nothing related to the protocol) is going on in
krakjoe/phpdbg github repo. There was now an xml-protocol branch for
three weeks before it got merged into krakjoe/phpdbg#master. You had
vast time to notice it and complain before, if you’d really have
cared.I would like to weigh in here. If we're talking about things in PHP core
repo, "we did it somewhere in public repo and nobody complained" is not
a good stance. People do literally hundreds of things around PHP in
public places, but not everything is part of PHP core. phpdbg now is.
That involves not only good parts (by-default acceptance by millions of
PHP users) but some obligations - like proper discussion and
notification. Of course, since master is not stable yet, we have
somewhat relaxed rules there, but even then introducing new debugging
protocol into PHP core seems to be something that warrants some
notification. As a person who spent significant time on implementing and
maintaining one of PHP debugging solutions in the past, I, for example,
would be interested to take a look into what is being checked into core
repo in this regard. However, the first note I see about this happening
is the commit messages. And that takes us back to old and not-so-good
"check in first, discuss later" times. With project of the size of PHP,
it having good process matters no less than having good code.
I'd like to everyone to stay grounded in reality and say that we have
been checking code into php-src for months, very very few people have
expressed an interest in what we were actually doing, you aren't one of
them Stas.
There was a remote protocol at the start, it still exists, it was
changed slightly. XML was added as an option.
None of the decisions taken were questionable, in the slightest. While
we should have given internals a heads up, it would have not have
changed the outcome.
We will notify internals of our intentions to make such changes in
future, if we thought there was any chance of any feedback before today,
we would already be doing so.
So saying "we had this branch for whole three weeks before merging it
into PHP repo" is not really saying much.That said, we are where we are, and I think it would be great if this
would somehow server as a starting point for developing a unified
protocol for debugging PHP. There are a number of good tools for
debugging PHP, and it would be a pity if everybody invented their own
protocols and required to install half-dozen of extensions to be
compatible with all tools doing the same in slightly different way.
We have so many unification efforts with PSR and the spec and so on, I'm
pretty sure we can make a protocol that would be workable for all,
debugging PHP is not exactly rocket surgery and there are not that many
things there that we couldn't find a common ground.
I quite like that idea, however, I'm stretched too thin to say that I
can do anything about it.
Cheers
Joe
disclaimer: I'm not overly interested in phpdbg, maybe I should
be, but for the moment I'm not.
I'd like to everyone to stay grounded in reality and say that we have
been checking code into php-src for months, very very few people have
expressed an interest in what we were actually doing, you aren't one of
them Stas.
The observation that very few people comment on your commits is correct,
the conclusion unfortunately isn't. The thing is: only very few people
are actively reviewing commits at all. Of those few only few look deeper
into commits ... unfortunately we don't have a good review rate. As long
as tests pass barely anybody complains about when things change. This is
not phpdbg specific but is true for most parts of PHP, on the engine we
have a few eyes, and a few extension maintainers have highlighting
filters on commits touching their extensions, but that's a minority.
This partly comes from people assuming that bigger changes will be
announced on internals, probably even with RFC. Even though there are
people who want an RFC&vote for everything I'd give extension (and sapi)
maintainers some freedom ... but the line is a tough one ...
The other reason is that reading commits is tough and requires a lot of
time ... I have no idea how to give incentives to do more review but we
desperately need that (again: not phpdbg specific but for the full
project) one approach to solve that would be to require reviews (either
in a Linux-like way with maintainers pulling changes and signing them
off, taking responsibility that way, or in a tool-based way like Android
with gerrit or such requiring reviews before a change is actually pushed
into the repo) to push any changes but then again our project is too
small and in some areas we can be happy to have somebody working on
bugfixes at all ... enforcing reviews there will slow us down and add
quite some process cost ... maybe somebody finds a good way ...
johannes
I'd like to everyone to stay grounded in reality and say that we have
been checking code into php-src for months, very very few people have
expressed an interest in what we were actually doing, you aren't one of
them Stas.
As much as I do not like the way this topic was brought to the list. A
point has been raised.
The chnages done in the latest patches, like the XML based protocol,
are not small changes and will affect us, our users and external tools
for a long time.I understand that discussing things too much prior to
apply it takes time, energy and sometimes could kill the motivation,
but this is how we reach consensus.
I do not think it is too late to have this discussion, maybe part of
the php specification too.I am a big fan of phpstorm, but it is by far
not the only tool around. The discussions here, if we filter out the
classic bashing and not so well formulated critics, try to figure out
if the choices are actually the best ofr php, now and for the next
years.
So. Yes, I also have to ask, humbly, both of you to also stay grounded
and accept to participate in a constructive discussion. Maybe push up
a RFC, documenting the current XML protocol, see the pros/cons, etc.
Other can also join this effort. I am sure we can find answers to all
these questions soon, if we leave the sentimental parts of this
discussions out of this, focusing on the actual technical and design
facts.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Am 26.10.2014 um 12:58 schrieb Pierre Joye pierre.php@gmail.com:
I'd like to everyone to stay grounded in reality and say that we have
been checking code into php-src for months, very very few people have
expressed an interest in what we were actually doing, you aren't one of
them Stas.As much as I do not like the way this topic was brought to the list. A
point has been raised.The chnages done in the latest patches, like the XML based protocol,
are not small changes and will affect us, our users and external tools
for a long time.I understand that discussing things too much prior to
apply it takes time, energy and sometimes could kill the motivation,
but this is how we reach consensus.I do not think it is too late to have this discussion, maybe part of
the php specification too.I am a big fan of phpstorm, but it is by far
not the only tool around. The discussions here, if we filter out the
classic bashing and not so well formulated critics, try to figure out
if the choices are actually the best ofr php, now and for the next
years.So. Yes, I also have to ask, humbly, both of you to also stay grounded
and accept to participate in a constructive discussion. Maybe push up
a RFC, documenting the current XML protocol, see the pros/cons, etc.
Other can also join this effort. I am sure we can find answers to all
these questions soon, if we leave the sentimental parts of this
discussions out of this, focusing on the actual technical and design
facts.Cheers,
Pierre
@pierrejoye | http://www.libgd.org http://www.libgd.org/
I’m fully aware that this is a phpng-style push in a bit smaller scope. And, despite whether that’s in spirit of open source (I’m not so sure if it really isn’t), it was something that had to be done. It’s not yet too late, we can still polish things which aren’t fine in the protocol.
Also, it was necessary to write the patch first to see how the protocol will also fit a bit into the code.
But then I had to restructure the code a lot. And later the thing got so big it got just too much maintenance work to simultaneously develop on the master branch (in krakjoe/phpdbg repo) and xml-protocol branch, so I merged everything. By that time I had a lot of unrelated features and the XML protocol then in master. (At that point I didn’t think it might become an issue). Then more than a week later I found it relatively stable (maybe some polishing left, but ± stable). I considered to have more discussion before, but it’d have blocked all the other improvements pending (would probably have been too much work to separate things again and push). And one really needs a starting base before real discussion can take place (The patch alone IMO is anyway too big to be reviewed as is). So, I pushed.
But let us not discuss if it really was a good idea to have it done that way - or not. Please rather discuss where the protocol can be improved, if it’s missing some features etc.
There is a Markdown file about the protocol in sapi/phpdbg/xml.md, which is documenting the XML responses one might get. I’m aware that it’s not really well structured, I appreciate any help there.
But mainly, please first review if the design of the protocol is okay.
Quick info (because it already caused some confusion): input commands are the same for xml protocol than for interactive mode. It’s just the output which differs.
Bob
p.s.: I don’t regret to have chosen XML - I mean, it’s now to late to discuss whether to choose XML or not, but I don’t regret the decisions I made there.
We will notify internals of our intentions to make such changes in
future, if we thought there was any chance of any feedback before today,
we would already be doing so.
"We will notify internals". Really? Sadly, this phpdbg stuff is part of
internals, so the "we" and "internals" mean the same thing. If you want
to run this as a private project, get it out of php-src.
cheers,
Derick
Am 26.10.2014 um 16:22 schrieb Derick Rethans derick@php.net:
We will notify internals of our intentions to make such changes in
future, if we thought there was any chance of any feedback before today,
we would already be doing so."We will notify internals". Really? Sadly, this phpdbg stuff is part of
internals, so the "we" and "internals" mean the same thing. If you want
to run this as a private project, get it out of php-src.cheers,
Derick
As already said, it was an one-time mistake. If there are any major things to happen in phpdbg, we’ll drop a mail first here and only merge after eventual discussion.
Thanks,
Bob
Am 26.10.2014 um 16:22 schrieb Derick Rethans derick@php.net:
We will notify internals of our intentions to make such changes in
future, if we thought there was any chance of any feedback before
today, we would already be doing so."We will notify internals". Really? Sadly, this phpdbg stuff is part
of internals, so the "we" and "internals" mean the same thing. If
you want to run this as a private project, get it out of php-src.As already said, it was an one-time mistake. If there are any major
things to happen in phpdbg, we’ll drop a mail first here and only
merge after eventual discussion.
That's good to hear.
But I have been speaking to the PhpStorm people here at ZendCon, and
they give a different version of the story why you didn't pick DBGp.
From what I understand, having to do another debugging protocol is
really the last thing that they want. Drop me a line (privately) to see
whether we can resolve the issues with the protocol that you had.
cheers,
Derick
Am 25.10.2014 um 20:20 schrieb Stas Malyshev:
somewhat relaxed rules there, but even then introducing new debugging
protocol into PHP core seems to be something that warrants some
notification.
That would have been my next question. I think it does not only
warrant notification but adherence to the RFC process.
On Sun, Oct 26, 2014 at 8:11 AM, Sebastian Bergmann sebastian@php.net
wrote:
Am 25.10.2014 um 20:20 schrieb Stas Malyshev:
somewhat relaxed rules there, but even then introducing new debugging
protocol into PHP core seems to be something that warrants some
notification.That would have been my next question. I think it does not only
warrant notification but adherence to the RFC process.--
As far as I can tell there are a couple of SAPIs(to be honest everything
except cli/cgi/fpm/embed and apache*) and even some exts(like mysql*,
pgsql, date, pcre, etc.) where there are dedicated maintainers who
seemingly can introduce new features without discussing it on the list or
following through the rfc process.
I'm not saying that this is a bad thing(on the contrary, I think that most
of the times this happens because the maintainer is the best suited for
making those decisions), but I think it would be nice if we could clarify
that what exact procedures do we want to be followed for exts/SAPIs inside
the php-src tree.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
That said, we are where we are, and I think it would be great if this
would somehow server as a starting point for developing a unified
protocol for debugging PHP.
It already exists: DBGp. It's implemented by dozens of editors and
plugins.
cheers,
Derick
Just a minor question, Derick. If you care about phpdbg, why are you
only dropping any comment about it by the time it got into php-src
repo?
Yes, my mistake. I should have voted -1, but as I thought there was a
conflict of interest, I stayed silent.
It’s known that all the development currently (except for
master, but that just was a merge and then a pure rewrite on top of
that merge, nothing related to the protocol) is going on in
krakjoe/phpdbg github repo. There was now an xml-protocol branch for
three weeks before it got merged into krakjoe/phpdbg#master. You had
vast time to notice it and complain before, if you’d really have
cared.
Sorry, but do you really expect people to follow some random person's
github repo+branch for something that gets source-dumped into php-src?
To reply to your question: why not use another debugger protocol? I
had first really looked for other protocols, but none really fitted
our needs. There was just DBGp which approximated our needs.
At the beginning I had tried to implement a slightly modified variant
of DBGp, but it accumulated minor differences here and there… And that
then doesn’t make much sense again.
Indeed - it's after all a documented protocol.
That was the time where we decided to implement our own protocol.
I don't even see why you want to write a whole new remote debugger in
the first place.
Before you ask, an incomplete list of such differences:
- connecting: phpdbg is the server, not the client (as opposed to what
DBGp requires)
And for good reasons... as it doesn't require people to do fiddly
command line stuff to debug multiple requests.
- no need for the proxy thing
- breakpoints: we have an opline-wise breaking (I have no idea, but
maybe an IDE might want to break before the fcall is done) doesn’t
fit into current list of attributes- It is under some circumstances possible to not be able to provide a
full response (e.g. we’ve done a hard interrupt (that means, instant,
asynchronous interrupt, even when engine is in control of it)) -
DBGp provides no mechanism to handle it- stdout, stderr commands also don’t really work with phpdbg — it’s always redirect mode
These three points are valid, but then there is (probably) also no
reason why it couldn't be added. And there is also no requirement for
stdout/stderr to be implemented.
cheers,
Derick
Am 26.10.2014 um 16:17 schrieb Derick Rethans derick@php.net:
Just a minor question, Derick. If you care about phpdbg, why are you
only dropping any comment about it by the time it got into php-src
repo?Yes, my mistake. I should have voted -1, but as I thought there was a
conflict of interest, I stayed silent.
That’s definitely your mistake. I also don’t remember that you seriously commented about the original RFC.
It’s known that all the development currently (except for
master, but that just was a merge and then a pure rewrite on top of
that merge, nothing related to the protocol) is going on in
krakjoe/phpdbg github repo. There was now an xml-protocol branch for
three weeks before it got merged into krakjoe/phpdbg#master. You had
vast time to notice it and complain before, if you’d really have
cared.Sorry, but do you really expect people to follow some random person's
github repo+branch for something that gets source-dumped into php-src?
I agree, that was a bad argument. That was just in comparison to phpng which was developed completely closed-source.
To reply to your question: why not use another debugger protocol? I
had first really looked for other protocols, but none really fitted
our needs. There was just DBGp which approximated our needs.At the beginning I had tried to implement a slightly modified variant
of DBGp, but it accumulated minor differences here and there… And that
then doesn’t make much sense again.Indeed - it's after all a documented protocol.
That was the time where we decided to implement our own protocol.
I don't even see why you want to write a whole new remote debugger in
the first place.
It wasn’t my idea. It was requested. There are issues on more than one bugtracker about phpdbg inclusion in the IDE.
See, people want it. So, I just give them the underlying mechanisms so that they can use it inside their favorite IDE.
Before you ask, an incomplete list of such differences:
- connecting: phpdbg is the server, not the client (as opposed to what
DBGp requires)And for good reasons... as it doesn't require people to do fiddly
command line stuff to debug multiple requests.
It still doesn’t. The IDE will handle it for you. (IDE creates a ssh connection and starts the phpdbg process - you don’t have to do anything.)
- no need for the proxy thing
- breakpoints: we have an opline-wise breaking (I have no idea, but
maybe an IDE might want to break before the fcall is done) doesn’t
fit into current list of attributes- It is under some circumstances possible to not be able to provide a
full response (e.g. we’ve done a hard interrupt (that means, instant,
asynchronous interrupt, even when engine is in control of it)) -
DBGp provides no mechanism to handle it- stdout, stderr commands also don’t really work with phpdbg — it’s always redirect mode
These three points are valid, but then there is (probably) also no
reason why it couldn't be added. And there is also no requirement for
stdout/stderr to be implemented.
Sorry, but I had the impression you weren’t cooperative with anyone. That’s why I didn’t approach you and try to discuss friendly.
cheers,
Derick
Thanks,
Bob
<snip> > AM sapi/phpdbg/xml.mdCommit: 2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Author: Bob Weinand bobwei9@hotmail.com Fri, 24 Oct 2014 19:29:50 +0200
Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d
Branches: masterLink: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Log:
Made phpdbg compatible with new engineAlthough this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up
with a new XML protocol for debugging.So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that
already exists? PHPDBG is difficult to use with its odd command line
"commands". And then I haven't even spoken about the pretentious
"awesomesauce" on http://phpdbg.com/ — a domain that's not even
under the PHP group's control.A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you don't
know how to use it.
I was being polite. I should have told them it is useles for any of our
users, instead of blaming it (wrongly) on my own ineptitude.
This is a strange sort of silence, and does not invite us to
co-operate.
Neither does calling internals people "dicks" or "knobs".
When you invented dbgp there were other protocols in existence,
There indeed where, but none of them were either open, or supporting
more than one language. As that was the goal, the people from
ActiveState—which still, ten years later have the best debugger
frontend—and I sat around a table and implemented a language-agnostic
debugging protocol. Used by Xdebug, and their debuggers for perl,
python, tcl, ruby, and XSLT.
not sure why we are expected to reuse a protocol.
Because DBGp is virtually a standard in the PHP world.
It so happens that the phpstorm guys working on integration seemed
keen on something new. I don't see the problem in that. If the only
reason it exists is for projects like phpstorm and they are actually
going to put time into trying something new, then why the hell not.
Well, if you'd have used DBGp, they wouldn't have to do any work.
I'm not sure why it matters what kind of language we use on
phpdbg.com, not sure why you think it should be under the control of
the php group either.
It shouldn't be anywhere near the PHP group either.
It is run as a personal project with source dumps into PHP. Things run
like that have no place in the core distribution. If you want to run
your personal project, go ahead - but keep php.net out of it.
If you had wanted to co-operate, you could have spoken to me at that
conference in person,
I tried. You disappeared after the first afternoon.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you don't
know how to use it.I was being polite. I should have told them it is useles for any of our
users, instead of blaming it (wrongly) on my own ineptitude.
Perhaps you could’ve actually talked about its benefits. I went to that talk too. You showed off stuff vld can do… and neglected to mention that phpdbg could do the same things.
--
Andrea Faulds
http://ajf.me/
A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you
don't know how to use it.I was being polite. I should have told them it is useles for any of
our users, instead of blaming it (wrongly) on my own ineptitude.Perhaps you could’ve actually talked about its benefits. I went to
that talk too. You showed off stuff vld can do… and neglected to
mention that phpdbg could do the same things.
Some of it, certainly. A future version of the talk (ie, next week at
ZendCon) will show the difference, so that the audience can judge for
themselves what is better.
cheers,
Derick
Am 26.10.2014 um 16:26 schrieb Derick Rethans derick@php.net:
A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you
don't know how to use it.I was being polite. I should have told them it is useles for any of
our users, instead of blaming it (wrongly) on my own ineptitude.Perhaps you could’ve actually talked about its benefits. I went to
that talk too. You showed off stuff vld can do… and neglected to
mention that phpdbg could do the same things.Some of it, certainly. A future version of the talk (ie, next week at
ZendCon) will show the difference, so that the audience can judge for
themselves what is better.cheers,
Derick
I’m certain it’ll still be biased somehow. Would be great if you could share with us what you’ll tell them, then maybe you can do a constructive talk about it.
Thanks,
Bob
Am 26.10.2014 um 16:09 schrieb Derick Rethans derick@php.net:
<snip> > AM sapi/phpdbg/xml.mdCommit: 2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Author: Bob Weinand bobwei9@hotmail.com Fri, 24 Oct 2014 19:29:50 +0200
Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d
Branches: masterLink: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Log:
Made phpdbg compatible with new engineAlthough this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up
with a new XML protocol for debugging.So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that
already exists? PHPDBG is difficult to use with its odd command line
"commands". And then I haven't even spoken about the pretentious
"awesomesauce" on http://phpdbg.com/ — a domain that's not even
under the PHP group's control.A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you don't
know how to use it.I was being polite. I should have told them it is useles for any of our
users, instead of blaming it (wrongly) on my own ineptitude.
No, xDebug has its use cases, phpdbg other use cases. They overlap many times. And it’s definitely not useless. I’ve already been able to debug real things with phpdbg and it works nicely for me.
This is a strange sort of silence, and does not invite us to
co-operate.Neither does calling internals people "dicks" or "knobs“.
That’s definitely a bad thing… could we please leave this genre of discussion out of internals?
When you invented dbgp there were other protocols in existence,
There indeed where, but none of them were either open, or supporting
more than one language. As that was the goal, the people from
ActiveState—which still, ten years later have the best debugger
frontend—and I sat around a table and implemented a language-agnostic
debugging protocol. Used by Xdebug, and their debuggers for perl,
python, tcl, ruby, and XSLT.
Hmm? I hardly could find anything about that with a few google searches...
not sure why we are expected to reuse a protocol.
Because DBGp is virtually a standard in the PHP world.
Because something is used by the only open-source thing in a field, it doesn’t make it a standard.
That you definitely have gotten wrongly.
It so happens that the phpstorm guys working on integration seemed
keen on something new. I don't see the problem in that. If the only
reason it exists is for projects like phpstorm and they are actually
going to put time into trying something new, then why the hell not.Well, if you'd have used DBGp, they wouldn't have to do any work.
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better protocol. That’s all.
I'm not sure why it matters what kind of language we use on
phpdbg.com http://phpdbg.com/, not sure why you think it should be under the control of
the php group either.It shouldn't be anywhere near the PHP group either.
It is run as a personal project with source dumps into PHP. Things run
like that have no place in the core distribution. If you want to run
your personal project, go ahead - but keep php.net http://php.net/ out of it.
phpdbg.com http://phpdbg.com/ is outdated, massively. That’s why we’re currently aiming to get a meaningful documentation to php.net http://php.net/.
If you had wanted to co-operate, you could have spoken to me at that
conference in person,I tried. You disappeared after the first afternoon.
Maybe, but if you wouldn’t have given such a negatively talk on the phpdbg part, he maybe wouldn’t have disappeared. Maybe you just could have talked to Joe before and discussed constructively about phpdbg.
cheers,
Derick--
http://derickrethans.nl http://derickrethans.nl/ | http://xdebug.org http://xdebug.org/
Like Xdebug? Consider a donation: http://xdebug.org/donate.php http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better protocol. That’s all.
PHPStorm like PHP-FIG have their own agendas which do not play well with
other groups of developers. Just because one thinks an idea is good does
not mean that everybody else has to adopt it. So what becomes 'main
stream' has to have common consensus and the voting rules provide that.
When was the vote on this rework taken?
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Am 26.10.2014 um 17:23 schrieb Lester Caine lester@lsces.co.uk:
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better protocol. That’s all.PHPStorm like PHP-FIG have their own agendas which do not play well with
other groups of developers. Just because one thinks an idea is good does
not mean that everybody else has to adopt it. So what becomes 'main
stream' has to have common consensus and the voting rules provide that.When was the vote on this rework taken?
--
Lester Caine - G8HFLContact - 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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
There wasn’t any vote and there won’t.
/dev/null likes to listen to your complaints why we should have voted on it.
But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing.
Next time we’ll put a notice a few days before, it’s promised, yes.
Thanks,
Bob
Am 26.10.2014 um 17:23 schrieb Lester Caine lester@lsces.co.uk:
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better protocol. That’s all.PHPStorm like PHP-FIG have their own agendas which do not play well with
other groups of developers. Just because one thinks an idea is good does
not mean that everybody else has to adopt it. So what becomes 'main
stream' has to have common consensus and the voting rules provide that.When was the vote on this rework taken?
--
Lester Caine - G8HFLContact - 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
Rainbow Digital Media - http://rainbowdigitalmedia.co.ukThere wasn’t any vote and there won’t.
/dev/null likes to listen to your complaints why we should have voted on it.
step back a bit here, stay professional, there is no need for passive
aggressiveness.
But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing.
From what I see, the complan is about the initial protocol and not about
how to improve it or not. This whole protocol business needed an RFC,
which I haven't seen. So we should come up with a good way of deciding
which protocol to use and how to implement it. Before this, I would strongly
vote to not incldue the current verison in PHP 7 at all. Also let me point
out that the code belogns to everyone and everyone will have to deal with it
so we better make an informed decision now.
Thanks
Am 26.10.2014 um 17:23 schrieb Lester Caine lester@lsces.co.uk:
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better protocol. That’s all.PHPStorm like PHP-FIG have their own agendas which do not play well with
other groups of developers. Just because one thinks an idea is good does
not mean that everybody else has to adopt it. So what becomes 'main
stream' has to have common consensus and the voting rules provide that.When was the vote on this rework taken?
--
Lester Caine - G8HFLContact - 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
Rainbow Digital Media - http://rainbowdigitalmedia.co.ukThere wasn’t any vote and there won’t.
/dev/null likes to listen to your complaints why we should have voted on it.
step back a bit here, stay professional, there is no need for passive
aggressiveness.But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing.
From what I see, the complan is about the initial protocol and not about
how to improve it or not. This whole protocol business needed an RFC,
which I haven't seen. So we should come up with a good way of deciding
which protocol to use and how to implement it. Before this, I would strongly
vote to not incldue the current verison in PHP 7 at all. Also let me point
out that the code belogns to everyone and everyone will have to deal with it
so we better make an informed decision now.
Hello people.
When PHP 5.6 has been released, few weeks/months ago, I explicitely
stated Ferenc (RMing 5.6 together with me), that it is not a normal
thing to have an external domain for phpdbg
This has never happened before, FWIR
Every code that is part of PHP, that is merged into php.net repo ,
falls under the PHP licence and the PHP process of doing things.
One chance is that today the subject shows to everybody and not only
RM wondering about this. Cool.
I'm all +1 to merge phpdbg web site content into official php.net documentation.
Guys, from an external POV, phpdbg seems very strange for people. Why
the hell does it have its own github repo and its own website ? This
is something that has never been seen for official php.net content
and our users are asking questions / assuming things.
Xdebug is not a php.net project, and Derick hash always managed to
keep this line clear to everybody (since 10 years now).
Derick has never asked to merge Xdebug to core, because (please
confirm) probably he wants to keep the lead on the project, and make
it evolve like he, as author and maintainer wants to. This is
something that can not happen to a PHP-project code.
phpdbg is under php.net ; every decision about phpdbg should then be
debatted with all the team, and new ideas, such as a protocol, RFC'ed,
whoever are the maintainers of the code. It's like that for every
piece of code, of every extension.
This is PHP process. If you dont want to adhere the rules, you can
keep your ideas yours, in a separate repo, like Derick does for
Xdebug.
People must understand that as soon as the code is part of the PHP
project, it is owned by the PHP project, and not a single/duo person
anymore.
Julien.Pauli
When PHP 5.6 has been released, few weeks/months ago, I explicitely
stated Ferenc (RMing 5.6 together with me), that it is not a normal
thing to have an external domain for phpdbgThis has never happened before, FWIR
Every code that is part of PHP, that is merged into php.net repo ,
falls under the PHP licence and the PHP process of doing things.One chance is that today the subject shows to everybody and not only
RM wondering about this. Cool.
I'm all +1 to merge phpdbg web site content into official php.net documentation.Guys, from an external POV, phpdbg seems very strange for people. Why
the hell does it have its own github repo and its own website ? This
is something that has never been seen for official php.net content
and our users are asking questions / assuming things.
Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net.
Andrea Faulds
http://ajf.me/
When PHP 5.6 has been released, few weeks/months ago, I explicitely
stated Ferenc (RMing 5.6 together with me), that it is not a normal
thing to have an external domain for phpdbgThis has never happened before, FWIR
Every code that is part of PHP, that is merged into php.net repo ,
falls under the PHP licence and the PHP process of doing things.One chance is that today the subject shows to everybody and not only
RM wondering about this. Cool.
I'm all +1 to merge phpdbg web site content into official php.net documentation.Guys, from an external POV, phpdbg seems very strange for people. Why
the hell does it have its own github repo and its own website ? This
is something that has never been seen for official php.net content
and our users are asking questions / assuming things.Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net.
Yes, this has been like that since the beggining of the PHP project.
The PHP project is a human, collaborative open source adventure before
anything else.
The code and the ideas written behind php.net are collaborative and
owned by everyone.
Julien.P
Am 28.10.2014 um 14:50 schrieb Andrea Faulds ajf@ajf.me:
When PHP 5.6 has been released, few weeks/months ago, I explicitely
stated Ferenc (RMing 5.6 together with me), that it is not a normal
thing to have an external domain for phpdbgThis has never happened before, FWIR
Every code that is part of PHP, that is merged into php.net repo ,
falls under the PHP licence and the PHP process of doing things.One chance is that today the subject shows to everybody and not only
RM wondering about this. Cool.
I'm all +1 to merge phpdbg web site content into official php.net documentation.Guys, from an external POV, phpdbg seems very strange for people. Why
the hell does it have its own github repo and its own website ? This
is something that has never been seen for official php.net content
and our users are asking questions / assuming things.Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net.
Andrea Faulds
http://ajf.me/ http://ajf.me/
Just a tiny update on this subject: we’re working on it.
https://github.com/bwoebi/phpdbg-docs https://github.com/bwoebi/phpdbg-docs
is in markdown what’ll be at some point in the official docs, I hope. It may take some little time to finish this, but then we’ll probably redirect phpdbg.com http://phpdbg.com/ page to php.net http://php.net/.
The phpdbg.com http://phpdbg.com/ page is currently just horribly outdated and a relict from that time before phpdbg was merged into php-src.
Bob Weinand
Hi!
phpdbg is under php.net ; every decision about phpdbg should then be
debatted with all the team, and new ideas, such as a protocol, RFC'ed,
whoever are the maintainers of the code. It's like that for every
piece of code, of every extension. This is PHP process. If you dont
want to
Do I understand it right that after all we've being discussing here
about not putting big new stuff into PHP without discussion, we've got
new stuff in phpdbg now merged not only to master but into the stable
branch of 5.6? Am I missing something here?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 29/10/2014 00:35, Stas Malyshev a écrit :
Hi!
phpdbg is under php.net ; every decision about phpdbg should then
be debatted with all the team, and new ideas, such as a protocol,
RFC'ed, whoever are the maintainers of the code. It's like that
for every piece of code, of every extension. This is PHP process.
If you dont want to
Do I understand it right that after all we've being discussing
here about not putting big new stuff into PHP without discussion,
we've got new stuff in phpdbg now merged not only to master but
into the stable branch of 5.6? Am I missing something here?
Can you please consider reverting everything to stable state (5.6.2),
and start discussing about pending changes ?
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlRQijwACgkQYUppBSnxahiPugCfWBHUcWQlFqq4tx/KrC95VqUK
CsAAoN4YcKahsp3WFIX0CkEA7g7gDhrV
=p9SK
-----END PGP SIGNATURE
Hi!
phpdbg is under php.net ; every decision about phpdbg should then be
debatted with all the team, and new ideas, such as a protocol, RFC'ed,
whoever are the maintainers of the code. It's like that for every
piece of code, of every extension. This is PHP process. If you dont
want to
Do I understand it right that after all we've being discussing here
about not putting big new stuff into PHP without discussion, we've got
new stuff in phpdbg now merged not only to master but into the stable
branch of 5.6? Am I missing something here?
If you are talking about the phpdbg new debugging protocol : this is right.
I think it clearly lacks discussion, RFC, concensus here, particularly
regarding the choice of the protocol.
We must absolutely use something open and efficient.
Using a closed protocol, that only one editor would be able to
implement ; is just a no-go ; for example.
Julien.P
Am 26.10.2014 um 17:23 schrieb Lester Caine lester@lsces.co.uk:
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better protocol. That’s all.PHPStorm like PHP-FIG have their own agendas which do not play well with
other groups of developers. Just because one thinks an idea is good does
not mean that everybody else has to adopt it. So what becomes 'main
stream' has to have common consensus and the voting rules provide that.When was the vote on this rework taken?
--
Lester Caine - G8HFLContact - 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
Rainbow Digital Media - http://rainbowdigitalmedia.co.ukThere wasn’t any vote and there won’t.
/dev/null likes to listen to your complaints why we should have voted on it.
step back a bit here, stay professional, there is no need for passive
aggressiveness.But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing.
From what I see, the complan is about the initial protocol and not about
how to improve it or not. This whole protocol business needed an RFC,
which I haven't seen. So we should come up with a good way of deciding
which protocol to use and how to implement it. Before this, I would strongly
vote to not incldue the current verison in PHP 7 at all. Also let me point
out that the code belogns to everyone and everyone will have to deal with it
so we better make an informed decision now.Hello people.
When PHP 5.6 has been released, few weeks/months ago, I explicitely
stated Ferenc (RMing 5.6 together with me), that it is not a normal
thing to have an external domain for phpdbgThis has never happened before, FWIR
FYI, PHP-FPM still has a separate website.
Cheers,
David
Am 26.10.2014 um 17:23 schrieb Lester Caine lester@lsces.co.uk:
Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
They just initially requested it because they didn’t knew any better protocol. That’s all.PHPStorm like PHP-FIG have their own agendas which do not play well with
other groups of developers. Just because one thinks an idea is good does
not mean that everybody else has to adopt it. So what becomes 'main
stream' has to have common consensus and the voting rules provide that.When was the vote on this rework taken?
--
Lester Caine - G8HFLContact - 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
Rainbow Digital Media - http://rainbowdigitalmedia.co.ukThere wasn’t any vote and there won’t.
/dev/null likes to listen to your complaints why we should have voted on it.
step back a bit here, stay professional, there is no need for passive
aggressiveness.But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing.
From what I see, the complan is about the initial protocol and not about
how to improve it or not. This whole protocol business needed an RFC,
which I haven't seen. So we should come up with a good way of deciding
which protocol to use and how to implement it. Before this, I would strongly
vote to not incldue the current verison in PHP 7 at all. Also let me point
out that the code belogns to everyone and everyone will have to deal with it
so we better make an informed decision now.Hello people.
When PHP 5.6 has been released, few weeks/months ago, I explicitely
stated Ferenc (RMing 5.6 together with me), that it is not a normal
thing to have an external domain for phpdbgThis has never happened before, FWIR
FYI, PHP-FPM still has a separate website.
Yep, this came to my ears recently.
I forgot about it.
I have nothing against external web site, as soon as the PHP doc is
clear, up-to-date and detailed.
For phpdbg , this is actually not the case (yet ?), there is WIP however.
Julien.P
Am 26.10.2014 um 16:09 schrieb Derick Rethans derick@php.net:
<snip> > AM sapi/phpdbg/xml.mdLog:
Made phpdbg compatible with new engineAlthough this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up
with a new XML protocol for debugging.So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that
already exists? PHPDBG is difficult to use with its odd command
line "commands". And then I haven't even spoken about the
pretentious "awesomesauce" on http://phpdbg.com/ — a domain that's
not even under the PHP group's control.A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you
don't know how to use it.I was being polite. I should have told them it is useles for any of
our users, instead of blaming it (wrongly) on my own ineptitude.No, xDebug has its use cases, phpdbg other use cases. They overlap
many times. And it’s definitely not useless. I’ve already been able to
debug real things with phpdbg and it works nicely for me.
I think this hits something on the spot: we don't define "scope" in an
RFC. And scope creep is never a good thing. I would suggest that you
come up with what scope phpdbg should solve, and don't get out of it.
This is a strange sort of silence, and does not invite us to
co-operate.Neither does calling internals people "dicks" or "knobs“.
That’s definitely a bad thing… could we please leave this genre of
discussion out of internals?
Sorry, I think that it should be called out just because it's not
appropriate in any case.
When you invented dbgp there were other protocols in existence,
There indeed where, but none of them were either open, or supporting
more than one language. As that was the goal, the people from
ActiveState—which still, ten years later have the best debugger
frontend—and I sat around a table and implemented a
language-agnostic debugging protocol. Used by Xdebug, and their
debuggers for perl, python, tcl, ruby, and XSLT.Hmm? I hardly could find anything about that with a few google
searches...
http://code.activestate.com/komodo/remotedebugging/
http://en.wikipedia.org/wiki/Project_Zero#PHP_support
http://hhvm.com/blog/6239/hhvm-3-3-0
not sure why we are expected to reuse a protocol.
Because DBGp is virtually a standard in the PHP world.
Because something is used by the only open-source thing in a field, it
doesn’t make it a standard. That you definitely have gotten wrongly.
I used "virtually" as adjective. I perhaps should have used "de
facto"[1].
[1] http://dictionary.reference.com/browse/de%20facto
It so happens that the phpstorm guys working on integration seemed
keen on something new. I don't see the problem in that. If the only
reason it exists is for projects like phpstorm and they are actually
going to put time into trying something new, then why the hell not.Well, if you'd have used DBGp, they wouldn't have to do any work.
Ask them at PhpStorm. They were pleased to not have to use DBGp for
it. They just initially requested it because they didn’t knew any
better protocol. That’s all.
So I actually did talk to them (in person, at ZendCon), and their
account of events is pretty much the exact opposite.
But in any case, that doesn't mean that reinventing the wheel again
makes sense. It's certainly not helpful to for users, for which you are
now fragmenting support.
If you had wanted to co-operate, you could have spoken to me at
that conference in person,I tried. You disappeared after the first afternoon.
Maybe, but if you wouldn’t have given such a negatively talk on the
phpdbg part, he maybe wouldn’t have disappeared.
Where you there? I don't think so. So please don't judge people on
here-say information.
cheers,
Derick
Am 26.10.2014 um 16:09 schrieb Derick Rethans derick@php.net:
<snip> > AM sapi/phpdbg/xml.mdLog:
Made phpdbg compatible with new engineAlthough this patch does make it work with PHP 7, it also does do
something absolutely different: it reinvents a wheel by coming up
with a new XML protocol for debugging.So far I've been silent on PHPDBG, but seriously, is it really not
possible to cooperate instead of reimplementating something that
already exists? PHPDBG is difficult to use with its odd command
line "commands". And then I haven't even spoken about the
pretentious "awesomesauce" on http://phpdbg.com/ — a domain that's
not even under the PHP group's control.A few weeks ago, I was at a conference where you told a room filled
with hundreds of developers that phpdbg was no good, because you
don't know how to use it.I was being polite. I should have told them it is useles for any of
our users, instead of blaming it (wrongly) on my own ineptitude.No, xDebug has its use cases, phpdbg other use cases. They overlap
many times. And it’s definitely not useless. I’ve already been able to
debug real things with phpdbg and it works nicely for me.I think this hits something on the spot: we don't define "scope" in an
RFC. And scope creep is never a good thing. I would suggest that you
come up with what scope phpdbg should solve, and don't get out of it.This is a strange sort of silence, and does not invite us to
co-operate.Neither does calling internals people "dicks" or "knobs“.
That’s definitely a bad thing… could we please leave this genre of
discussion out of internals?Sorry, I think that it should be called out just because it's not
appropriate in any case.When you invented dbgp there were other protocols in existence,
There indeed where, but none of them were either open, or supporting
more than one language. As that was the goal, the people from
ActiveState—which still, ten years later have the best debugger
frontend—and I sat around a table and implemented a
language-agnostic debugging protocol. Used by Xdebug, and their
debuggers for perl, python, tcl, ruby, and XSLT.Hmm? I hardly could find anything about that with a few google
searches...http://code.activestate.com/komodo/remotedebugging/
http://en.wikipedia.org/wiki/Project_Zero#PHP_support
http://hhvm.com/blog/6239/hhvm-3-3-0not sure why we are expected to reuse a protocol.
Because DBGp is virtually a standard in the PHP world.
Because something is used by the only open-source thing in a field, it
doesn’t make it a standard. That you definitely have gotten wrongly.I used "virtually" as adjective. I perhaps should have used "de
facto"[1].[1] http://dictionary.reference.com/browse/de%20facto
It so happens that the phpstorm guys working on integration seemed
keen on something new. I don't see the problem in that. If the only
reason it exists is for projects like phpstorm and they are actually
going to put time into trying something new, then why the hell not.Well, if you'd have used DBGp, they wouldn't have to do any work.
Ask them at PhpStorm. They were pleased to not have to use DBGp for
it. They just initially requested it because they didn’t knew any
better protocol. That’s all.So I actually did talk to them (in person, at ZendCon), and their
account of events is pretty much the exact opposite.But in any case, that doesn't mean that reinventing the wheel again
makes sense. It's certainly not helpful to for users, for which you are
now fragmenting support.If you had wanted to co-operate, you could have spoken to me at
that conference in person,I tried. You disappeared after the first afternoon.
Maybe, but if you wouldn’t have given such a negatively talk on the
phpdbg part, he maybe wouldn’t have disappeared.Where you there? I don't think so. So please don't judge people on
here-say information.cheers,
Derick
Morning,
This is new information to me, I was lead to believe that phpstorm were
happy to invest time in it.
I asked bob for the xml stuff to be reverted from 5.6 and master
yesterday and be developed elsewhere.
This now *must* happen, it doesn't belong in php-src at this point.
If development of a remote protocol is to be carried out, it *must* be
carried out in an experimental branch of php-src, or on krakjoe/phpdbg.
About scope, we never intended to write a remote debugger suitable for
everything, we were pushed down that road by what people seem to want.
phpdbg is fundamentally different to xdebug, it cannot be loaded in any
SAPI, it doesn't even make sense to talk about using it in the same way
as xdebug, it does not and can not do all the things.
I'm quite happy for phpdbg to have better remote abilities, I even said
that we should use dbgp https://github.com/krakjoe/phpdbg/issues/105
I'd be even happier if we left that to xdebug, we never wanted to focus
on that in the beginning.
The remote ability that phpdbg had at the beginning was for no more
than giving people uncomfortable with using a shell, or not able to use
a shell, an option. It worked, but was arguably terrible, and an
afterthought.
I think it would be better for everyone if we dropped the idea of
support for remote debugging, I won't stop it going ahead if bob still
wants to work on it, but I do regard it as feature creep.
Cheers
Joe
This is new information to me, I was lead to believe that phpstorm werehappy to invest time in it.
I asked bob for the xml stuff to be reverted from 5.6 and masteryesterday and be developed elsewhere.
This now *must* happen, it doesn't belong in php-src at this point. If development of a remote protocol is to be carried out, it *must* becarried out in an experimental branch of php-src, or on krakjoe/phpdbg.
About scope, we never intended to write a remote debugger suitable foreverything, we were pushed down that road by what people seem to want.
phpdbg is fundamentally different to xdebug, it cannot be loaded in anySAPI, it doesn't even make sense to talk about using it in the same way
as xdebug, it does not and can not do all the things.I'm quite happy for phpdbg to have better remote abilities, I even saidthat we should use dbgp https://github.com/krakjoe/phpdbg/issues/105
I'd be even happier if we left that to xdebug, we never wanted to focuson that in the beginning.
The remote ability that phpdbg had at the beginning was for no morethan giving people uncomfortable with using a shell, or not able to use
a shell, an option. It worked, but was arguably terrible, and an
afterthought.I think it would be better for everyone if we dropped the idea ofsupport for remote debugging, I won't stop it going ahead if bob still
wants to work on it, but I do regard it as feature creep.
I see a clear usecase for remote debugging and shell. Same shell usage
as now but with remote host support. I do that a lot for many other
languages, testing stuff in various VMs. It is amazingly handy to be
able to do that.
As of 5.6, I am not sure either with other big changes as 5.6 is
stable now, huge changes (and not well tested, builds were broken
f.e.) should be done after (public) discussions, if necessary.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
This is new information to me, I was lead to believe that phpstorm werehappy to invest time in it.
I asked bob for the xml stuff to be reverted from 5.6 and masteryesterday and be developed elsewhere.
This now *must* happen, it doesn't belong in php-src at this point. If development of a remote protocol is to be carried out, it *must* becarried out in an experimental branch of php-src, or on krakjoe/phpdbg.
About scope, we never intended to write a remote debugger suitable foreverything, we were pushed down that road by what people seem to want.
phpdbg is fundamentally different to xdebug, it cannot be loaded in anySAPI, it doesn't even make sense to talk about using it in the same way
as xdebug, it does not and can not do all the things.I'm quite happy for phpdbg to have better remote abilities, I even saidthat we should use dbgp https://github.com/krakjoe/phpdbg/issues/105
I'd be even happier if we left that to xdebug, we never wanted to focuson that in the beginning.
The remote ability that phpdbg had at the beginning was for no morethan giving people uncomfortable with using a shell, or not able to use
a shell, an option. It worked, but was arguably terrible, and an
afterthought.I think it would be better for everyone if we dropped the idea ofsupport for remote debugging, I won't stop it going ahead if bob still
wants to work on it, but I do regard it as feature creep.I see a clear usecase for remote debugging and shell. Same shell usage
as now but with remote host support. I do that a lot for many other
languages, testing stuff in various VMs. It is amazingly handy to be
able to do that.As of 5.6, I am not sure either with other big changes as 5.6 is
stable now, huge changes (and not well tested, builds were broken
f.e.) should be done after (public) discussions, if necessary.Cheers,
Morning,
Some remote ability is helpful, I agree.
The kind of remote ability we had at the start is, in my opinion, as
far as it ever really needs to go.
The use case for remote debugging, using any sapi, will always be best
satisfied by xdebug.
If we are to develop the remote debugging features with an extended or
new version of dbgp, then 7 is the only sensible target for that I
think, if there is a sensible target.
Cheers
Joe