Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78345 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30019 invoked from network); 26 Oct 2014 15:26:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Oct 2014 15:26:13 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.100 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.100 blu004-omc2s25.hotmail.com Received: from [65.55.111.100] ([65.55.111.100:62214] helo=BLU004-OMC2S25.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/3C-36207-5921D445 for ; Sun, 26 Oct 2014 10:26:13 -0500 Received: from BLU436-SMTP124 ([65.55.111.72]) by BLU004-OMC2S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 26 Oct 2014 08:26:10 -0700 X-TMN: [7gNhriga9aPuTL+tf+s6E+BN5XutwLvQ] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) In-Reply-To: Date: Sun, 26 Oct 2014 16:26:05 +0100 CC: PHP Developers Mailing List Content-Transfer-Encoding: quoted-printable References: <1414217636.2624.89.camel@localhost.localdomain> <1414229963.2624.103.camel@localhost.localdomain> To: Derick Rethans X-Mailer: Apple Mail (2.1990.1) X-OriginalArrivalTime: 26 Oct 2014 15:26:08.0310 (UTC) FILETIME=[2A577560:01CFF131] Subject: Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...) From: bobwei9@hotmail.com (Bob Weinand) > Am 26.10.2014 um 16:17 schrieb Derick Rethans : >=20 > On Sat, 25 Oct 2014, Weinand Bob wrote: >=20 >> Just a minor question, Derick. If you care about phpdbg, why are you=20= >> only dropping any comment about it by the time it got into php-src=20 >> repo? >=20 > Yes, my mistake. I should have voted -1, but as I thought there was a=20= > conflict of interest, I stayed silent. That=E2=80=99s definitely your mistake. I also don=E2=80=99t remember = that you seriously commented about the original RFC. >> It=E2=80=99s known that all the development currently (except for=20 >> master, but that just was a merge and then a pure rewrite on top of=20= >> that merge, nothing related to the protocol) is going on in=20 >> krakjoe/phpdbg github repo. There was now an xml-protocol branch for=20= >> three weeks before it got merged into krakjoe/phpdbg#master. You had=20= >> vast time to notice it and complain before, if you=E2=80=99d really = have=20 >> cared. >=20 > Sorry, but do you really expect people to follow some random person's=20= > 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=20= >> had first really looked for other protocols, but none really fitted=20= >> our needs. There was just DBGp which approximated our needs. >=20 >> At the beginning I had tried to implement a slightly modified variant=20= >> of DBGp, but it accumulated minor differences here and there=E2=80=A6 = And that=20 >> then doesn=E2=80=99t make much sense again. >=20 > Indeed - it's after all a documented protocol. >=20 >> That was the time where we decided to implement our own protocol. >=20 > I don't even see *why* you want to write a whole new remote debugger = in=20 > the first place. It wasn=E2=80=99t 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: >>=20 >> - connecting: phpdbg is the server, not the client (as opposed to = what=20 >> DBGp requires) >=20 > And for good reasons... as it doesn't require people to do fiddly=20 > command line stuff to debug multiple requests. It still doesn=E2=80=99t. The IDE will handle it for you. (IDE creates a = ssh connection and starts the phpdbg process - you don=E2=80=99t have to = do anything.) >> - no need for the proxy thing >=20 >> - breakpoints: we have an opline-wise breaking (I have no idea, but=20= >> maybe an IDE might want to break before the fcall is done) doesn=E2=80= =99t=20 >> fit into current list of attributes >> - It is under some circumstances possible to not be able to provide a=20= >> full response (e.g. we=E2=80=99ve done a hard interrupt (that means, = instant,=20 >> asynchronous interrupt, even when engine is in control of it)) -=20 >> DBGp provides no mechanism to handle it >> - stdout, stderr commands also don=E2=80=99t really work with phpdbg = =E2=80=94 it=E2=80=99s always redirect mode >=20 > These three points are valid, but then there is (probably) also no=20 > reason why it couldn't be added. And there is also no requirement for=20= > stdout/stderr to be implemented. Sorry, but I had the impression you weren=E2=80=99t cooperative with = anyone. That=E2=80=99s why I didn=E2=80=99t approach you and try to = discuss friendly. > cheers, > Derick > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Thanks, Bob=