Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Wed, 29 Oct 2014 17:08:00 -0700 (PDT)
To: Bob Weinand <bobwei9@hotmail.com>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <BLU437-SMTP60D9697FF20A5AD3E5C439E2910@phx.gbl>
Message-ID: <alpine.DEB.2.11.1410291648210.13538@whisky.home.derickrethans.nl>
References: <php-mail-d1dee1060d0e519b421e241f31037078549681831@git.php.net> <alpine.DEB.2.11.1410242103530.4012@whisky.home.derickrethans.nl> <1414217636.2624.89.camel@localhost.localdomain> <alpine.DEB.2.11.1410261047380.4012@whisky.home.derickrethans.nl>
 <BLU437-SMTP60D9697FF20A5AD3E5C439E2910@phx.gbl>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2091643263-1414627682=:13538"
Subject: Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made
 phpdbg compatible with new engine: ...)
From: derick@php.net (Derick Rethans)

--8323329-2091643263-1414627682=:13538
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sun, 26 Oct 2014, Bob Weinand wrote:

>=20
> > Am 26.10.2014 um 16:09 schrieb Derick Rethans <derick@php.net>:
> >=20
> > On Sat, 25 Oct 2014, Joe Watkins wrote:
> >=20
> >> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
> >>> On Fri, 24 Oct 2014, Bob Weinand wrote:
> >>>>=20
> >>>> Log:
> >>>> Made phpdbg compatible with new engine
> >>>=20
> >>> <snip>
> >>>>  AM  sapi/phpdbg/xml.md
> >>>=20
> >>> Although this patch does make it work with PHP 7, it also does do=20
> >>> something absolutely different: it reinvents a wheel by coming up=20
> >>> with a new XML protocol for debugging.
> >>>=20
> >>> So far I've been silent on PHPDBG, but seriously, is it really not=20
> >>> possible to cooperate instead of reimplementating something that=20
> >>> already exists? PHPDBG is difficult to use with its odd command=20
> >>> line "commands". And then I haven't even spoken about the=20
> >>> pretentious "awesomesauce" on http://phpdbg.com/ =E2=80=94 a domain t=
hat's=20
> >>> not even under the PHP group's control.
> >>=20
> >> A few weeks ago, I was at a conference where you told a room filled=20
> >> with hundreds of developers that phpdbg was no good, because you=20
> >> don't know how to use it.
> >=20
> > I was being polite. I should have told them it is useles for any of=20
> > our users, instead of blaming it (wrongly) on my own ineptitude.
>=20
> No, xDebug has its use cases, phpdbg other use cases. They overlap=20
> many times. And it=E2=80=99s definitely not useless. I=E2=80=99ve already=
 been able to=20
> 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=20
RFC. And scope creep is never a good thing. I would suggest that you=20
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=20
> >> co-operate.
> >=20
> > Neither does calling internals people "dicks" or "knobs=E2=80=9C.
>=20
> That=E2=80=99s definitely a bad thing=E2=80=A6 could we please leave this=
 genre of=20
> discussion out of internals?

Sorry, I think that it should be called out *just* because it's not=20
appropriate in any case.

> >> When you invented dbgp there were other protocols in existence,
> >=20
> > There indeed where, but none of them were either open, or supporting=20
> > more than one language. As that was the goal, the people from=20
> > ActiveState=E2=80=94which *still, ten years later* have the best debugg=
er=20
> > frontend=E2=80=94and I sat around a table and implemented a=20
> > language-agnostic debugging protocol. Used by Xdebug, and their=20
> > debuggers for perl, python, tcl, ruby, and XSLT.
>=20
> Hmm? I hardly could find anything about that with a few google=20
> 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
>=20
> >> not sure why we are expected to reuse a protocol.
> >=20
> > Because DBGp is virtually a standard in the PHP world.=20
>=20
> Because something is used by the only open-source thing in a field, it=20
> doesn=E2=80=99t make it a standard. That you definitely have gotten wrong=
ly.

I used "virtually" as adjective. I perhaps should have used "de=20
facto"[1].

[1] http://dictionary.reference.com/browse/de%20facto

>=20
> >> It so happens that the phpstorm guys working on integration seemed=20
> >> keen on something new. I don't see the problem in that. If the only=20
> >> reason it exists is for projects like phpstorm and they are actually=
=20
> >> going to put time into trying something new, then why the hell not.
> >=20
> > Well, if you'd have used DBGp, they wouldn't have to do any work.
>=20
> Ask them at PhpStorm. They were pleased to not have to use DBGp for=20
> it. They just initially requested it because they didn=E2=80=99t knew any=
=20
> better protocol. That=E2=80=99s all.

So I actually did talk to them (in person, at ZendCon), and their=20
account of events is pretty much the exact opposite.=20

But in any case, that doesn't mean that reinventing the wheel again=20
makes sense. It's certainly not helpful to for users, for which you are=20
now fragmenting support.

> >> If you had wanted to co-operate, you could have spoken to me at=20
> >> that conference in person,
> >=20
> > I tried. You disappeared after the first afternoon.
>=20
> Maybe, but if you wouldn=E2=80=99t have given such a negatively talk on t=
he=20
> phpdbg part, he maybe wouldn=E2=80=99t have disappeared.

Where you there? I don't think so. So please don't judge people on=20
here-say information.

cheers,
Derick
--8323329-2091643263-1414627682=:13538--