From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael-David Fiszer Newsgroups: gmane.emacs.bugs Subject: bug#50669: 28.0.50; python-shell-send-string leads to "nesting exceeds `max-lisp-eval-depth`" error Date: Wed, 22 Sep 2021 00:17:27 +0300 Message-ID: References: <87zgs9gcd3.fsf@gmail.com> <8735q0lf1w.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006dd4ae05cc87edce" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9667"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50669@debbugs.gnu.org To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 21 23:18:20 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mSn9g-0002Jr-6m for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Sep 2021 23:18:20 +0200 Original-Received: from localhost ([::1]:35186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSn9e-0000ne-HN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Sep 2021 17:18:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54638) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSn9O-0000n7-SC for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 17:18:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36632) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mSn9O-0007SR-Kp for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 17:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mSn9O-0005iH-Cf for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 17:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael-David Fiszer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Sep 2021 21:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50669 X-GNU-PR-Package: emacs Original-Received: via spool by 50669-submit@debbugs.gnu.org id=B50669.163225906721926 (code B ref 50669); Tue, 21 Sep 2021 21:18:02 +0000 Original-Received: (at 50669) by debbugs.gnu.org; 21 Sep 2021 21:17:47 +0000 Original-Received: from localhost ([127.0.0.1]:48178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSn99-0005ha-2X for submit@debbugs.gnu.org; Tue, 21 Sep 2021 17:17:47 -0400 Original-Received: from mail-vs1-f51.google.com ([209.85.217.51]:37410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSn97-0005dZ-M3 for 50669@debbugs.gnu.org; Tue, 21 Sep 2021 17:17:46 -0400 Original-Received: by mail-vs1-f51.google.com with SMTP id q66so729617vsa.4 for <50669@debbugs.gnu.org>; Tue, 21 Sep 2021 14:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2j0AhYCgYSsS1+Ymy9qH/EM6c4ppnun+XyGsztXg1e8=; b=ZSxZOC7XmbDJvqE1QW3xyC2gZKJpn8qwklFZJxvHNomkD+TTeLdyfGlTL9p72Knsmx wXQ4VxxcAHYTU9OPjUqWnfvJFiFkQGnwapQcnMVNzuqNzo9weQ8+vlO8RGUCMupsTNoh rjbRVEV5ZCdxQfTC4oViy4P6jqwjHJMNEJYGR5cnWNErKJyV7V5gz0POYUCHlkHpWIk9 MH0KCp4TXt3RRJWyIon1Cb6OWyJBm1oGnbvy7PNeOi2UutFmHJUQ/BMxWtiz6/b9bkXt 5l314iRAMWgjY7TwzFiC1min8gxPFrjC8l2RuAK4HHhEnLZTShtQynT3FlYgz2fzgpbF pqCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2j0AhYCgYSsS1+Ymy9qH/EM6c4ppnun+XyGsztXg1e8=; b=VAyR46RA0KNevNqfsNrFRFU7QegZlpOLfLdilZdXRBNT7SArA3iJK3TfjeLvqrBf4V S7f26s7Z3ayhSw2WTtBWeUFKDTRPBxHgHyccGuk7DaDM5bbC1WLfwHoGlapAIJ4VFycq 3WlltRoJE/gmggUOeuhdJxlKAux40wpUFQ98ZrIIGxQmcHe1BhZcd1/77Cjf++6BJPRo SoCUBkdu/Nz5VjWhYnX7WPP51vs5HG5uT5X4IEqJnpzbmSgQ2Tqsz+zL1bkQdt3iPjut lzvwOwrP8i1nqHNIiKDDOp0jGA3NIQMuEMP0i0p9bXBcMa57OuDga8vx/8KsdEY3g2L5 UiAw== X-Gm-Message-State: AOAM532ZrmmV15apV55R5vcpUJNFKhQ0qd43M0XLsGjQZajW/je8nCPD eL6j6POrEkCY50SDbcHOLQ5kxD7Jb24y0i/bG50= X-Google-Smtp-Source: ABdhPJyFBUG06Q9UR2b3bSEJJ2k0/WM0MSNyUABMV1QodV+sUBWqJ223KKunzZBtjgTdvYInujU9C9qsjFBpZxmmQNg= X-Received: by 2002:a05:6102:22f1:: with SMTP id b17mr22977664vsh.10.1632259059601; Tue, 21 Sep 2021 14:17:39 -0700 (PDT) In-Reply-To: <8735q0lf1w.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:215042 Archived-At: --0000000000006dd4ae05cc87edce Content-Type: text/plain; charset="UTF-8" Hi! - I'm pretty sure I'm on the master branch. I don't clone from git, but I compared my version of python.el with this https://github.com/emacs-mirror/emacs/commit/6cfc312d7196d7c7c70e7030b344891ecea8c4f1#diff-f808b0589744f83f41d9f581e8b07001145598d2a2aa07fd40c1d20ee35df762 and it looks up to date. - Regarding the recursive calls, I tried to look into it, and what I found was very confusing. - The tests I sent on number of characters, I believe establish that the issue only arises when the string is long enough for python-shell-send-string to save to a file and call python-shell-send file. - The backtrace - I sent to you. I suppose it's hard to decipher. - I then tried setting a breakpoint in 'python-shell-send-string. If I step through commands there, I see myself looping through this function again and again (creating more and more files, which is eventually what leads to the error). Buf *if* I step into 'python-shell-send-file when going through the difference expressions of 'python-shell-send-string, I get into the function (which indeed calls 'comint-send-string, not 'python-shell-send-string... and at this point, instead of returning to the *beginning* of python-shell-send string, I end up exiting python-shell-send-string and everything works. - In other words, the problem does not arise in edebug mode *if* I step into python-shell-send-file when python-shell-send-string calls it. This is very weird, sounds like perhaps some async issue... Very odd. On Sun, Sep 19, 2021 at 7:13 PM Augusto Stoffel wrote: > Hi David, > > So, I think the main thing is to figure out which functions are calling > themselves recursively. 'python-shell-send-file' doesn't call > 'python-shell-send-string' anymore, so that can't be it (are you sure > you are using today's master branch?). > > Another crazy attempt would be this: > > (let ((process-connection-type nil) > (python-shell-completion-native-enable nil)) > (run-python)) > > Nevermind the initial warnings, does it work for you afterwards? > --0000000000006dd4ae05cc87edce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

- I'm pretty sure I'm on the master bra= nch. I don't clone from git, but I
compared my version of python.el = with this
https://github.com/emacs-mirror/emacs/commit= /6cfc312d7196d7c7c70e7030b344891ecea8c4f1#diff-f808b0589744f83f41d9f581e8b0= 7001145598d2a2aa07fd40c1d20ee35df762
and it looks up to date.
- Regarding the recursive calls, I tried to look into it, and what I found= was very confusing.
=C2=A0 - The tests I sent on number of characters,= I believe establish that the issue only arises when the string is long eno= ugh for python-shell-send-string to save to a file and call python-shell-se= nd file.
=C2=A0 - The backtrace - I sent to you. I suppose it's hard= to decipher.
=C2=A0 - I then tried setting a breakpoint in 'python-= shell-send-string. If I step through commands there, I see myself looping t= hrough this function again and again (creating more and more files, which i= s eventually what leads to the error). Buf *if* I step into 'python-she= ll-send-file when going through the difference expressions of 'python-s= hell-send-string, I get into the function (which indeed calls 'comint-s= end-string, not 'python-shell-send-string... and at this point, instead= of returning to the *beginning* of python-shell-send string, I end up exit= ing python-shell-send-string and everything works.
=C2=A0 =C2=A0 =C2=A0= - In other words, the problem does not arise in edebug mode *if* I step in= to python-shell-send-file when python-shell-send-string calls it.

Th= is is very weird, sounds like perhaps some async issue... Very odd.

On S= un, Sep 19, 2021 at 7:13 PM Augusto Stoffel <arstoffel@gmail.com> wrote:
Hi David,

So, I think the main thing is to figure out which functions are calling
themselves recursively.=C2=A0 'python-shell-send-file' doesn't = call
'python-shell-send-string' anymore, so that can't be it (are yo= u sure
you are using today's master branch?).

Another crazy attempt would be this:

=C2=A0 =C2=A0 =C2=A0(let ((process-connection-type nil)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(python-shell-completion-native-en= able nil))
=C2=A0 =C2=A0 =C2=A0 =C2=A0(run-python))

Nevermind the initial warnings, does it work for you afterwards?
--0000000000006dd4ae05cc87edce--