Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78456 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23336 invoked from network); 30 Oct 2014 08:36:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Oct 2014 08:36:16 -0000 Authentication-Results: pb1.pair.com smtp.mail=pthreads@pthreads.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=pthreads@pthreads.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.212.177 cause and error) X-PHP-List-Original-Sender: pthreads@pthreads.org X-Host-Fingerprint: 209.85.212.177 mail-wi0-f177.google.com Received: from [209.85.212.177] ([209.85.212.177:59574] helo=mail-wi0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 97/00-23087-E78F1545 for ; Thu, 30 Oct 2014 03:36:15 -0500 Received: by mail-wi0-f177.google.com with SMTP id ex7so6682034wid.10 for ; Thu, 30 Oct 2014 01:36:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; bh=E5ZHZ84tCpMRAyfboo/b44JpzjmY4c4YdEzREY7CZT4=; b=WtGBjp+/w3LyUV3J+ppTgOLHG5i/tgxujFt48B/7asm5eYDcAN0i3JoUW+J2nf9+KX bLv1jZxjgUDKni1aIWzZLFDLt1M6tE8ZvzvZpgDcPDHLvoSZfkI5MMBNP7WsAtwUpAz4 VUnQcCUwHkuJlP18PwAe/paYUHK0+TkBhqU0jT8YT9Om6921Um1L/mR/YcTdU0v13tMG 06mZgFQx4T+GCBhC3LMHOz0B/2+BV3N6BGIK12lPa8n2zsGDQnkYn4KcYn0puJAHhwzj N4uKn1o5qfr7qG8/TjT3Dq0dK4ay74WNHh8zA0h9MDXTLRQUSTlJnrTTAk0rlrl6Uu7B dczA== X-Gm-Message-State: ALoCoQn7XUfvkj6Tj3lgMTfopLE34BGuKkU2b/k2qF5wRJcy+oaLze/HvLlmBgJVO2ZwvX9WALCi X-Received: by 10.180.14.226 with SMTP id s2mr18187232wic.61.1414658170397; Thu, 30 Oct 2014 01:36:10 -0700 (PDT) Received: from [192.168.1.67] (host86-166-38-10.range86-166.btcentralplus.com. [86.166.38.10]) by mx.google.com with ESMTPSA id bj7sm7858368wjc.33.2014.10.30.01.36.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 Oct 2014 01:36:09 -0700 (PDT) Message-ID: <1414658167.2624.247.camel@localhost.localdomain> To: Pierre Joye Cc: Derick Rethans , Bob Weinand , PHP Developers Mailing List Date: Thu, 30 Oct 2014 08:36:07 +0000 In-Reply-To: References: <1414217636.2624.89.camel@localhost.localdomain> <1414655336.2624.228.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Thu, 2014-10-30 at 14:56 +0700, Pierre Joye wrote: > > 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. > > 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