Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78454
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.42 cause and error)
Message-ID: <1414655336.2624.228.camel@localhost.localdomain>
To: Derick Rethans <derick@php.net>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP Developers Mailing List
	 <internals@lists.php.net>
Date: Thu, 30 Oct 2014 07:48:56 +0000
In-Reply-To: <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>
	 <alpine.DEB.2.11.1410291648210.13538@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made
 phpdbg compatible with new engine: ...)
From: pthreads@pthreads.org (Joe Watkins)

On Wed, 2014-10-29 at 17:08 -0700, Derick Rethans wrote:
> On Sun, 26 Oct 2014, Bob Weinand wrote:
> 
> > 
> > > Am 26.10.2014 um 16:09 schrieb Derick Rethans <derick@php.net>:
> > > 
> > > On Sat, 25 Oct 2014, Joe Watkins wrote:
> > > 
> > >> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
> > >>> On Fri, 24 Oct 2014, Bob Weinand wrote:
> > >>>> 
> > >>>> Log:
> > >>>> Made phpdbg compatible with new engine
> > >>> 
> > >>> <snip>
> > >>>>  AM  sapi/phpdbg/xml.md
> > >>> 
> > >>> 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.
> > >> 
> > >> 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
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