From unknown Sat Jun 21 10:43:49 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#3794 <3794@debbugs.gnu.org> To: bug#3794 <3794@debbugs.gnu.org> Subject: Status: Error in json from gdb-ui Reply-To: bug#3794 <3794@debbugs.gnu.org> Date: Sat, 21 Jun 2025 17:43:49 +0000 retitle 3794 Error in json from gdb-ui reassign 3794 emacs submitter 3794 Herbert Euler severity 3794 normal thanks From herberteuler@hotmail.com Thu Jul 9 05:14:39 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 9 Jul 2009 12:14:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-5.9 required=4.0 tests=FOURLA,HAS_PACKAGE autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n69CEYf7023023 for ; Thu, 9 Jul 2009 05:14:36 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOsWI-0007bS-CI for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 08:14:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOsWD-0007Ra-Hh for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 08:14:33 -0400 Received: from [199.232.76.173] (port=44475 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOsWD-0007RQ-E4 for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 08:14:29 -0400 Received: from bay0-omc2-s40.bay0.hotmail.com ([65.54.246.176]:38429) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOsWC-00024O-RK for bug-gnu-emacs@gnu.org; Thu, 09 Jul 2009 08:14:29 -0400 Received: from BAY143-W19 ([65.55.154.54]) by bay0-omc2-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 05:14:28 -0700 Message-ID: Content-Type: multipart/mixed; boundary="_848dc0c8-68f9-4201-8f64-e853ada3301d_" X-Originating-IP: [124.127.101.0] From: Herbert Euler To: Subject: Error in json from gdb-ui Date: Thu, 9 Jul 2009 20:14:27 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2009 12:14:28.0192 (UTC) FILETIME=[CE6A7600:01CA008E] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ --_848dc0c8-68f9-4201-8f64-e853ada3301d_ Content-Type: multipart/alternative; boundary="_e2deff4e-24f6-406d-8616-eacd29f4fbeb_" --_e2deff4e-24f6-406d-8616-eacd29f4fbeb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Package: emacs Version: 23.1.50.11 (This is the CVS HEAD version of emacs.) I tried M-x gdb to run emacs under gdb. The command line was gdb -i=3Dmi ~/src/emacs/src/emacs and I got the error '(json-object-format ":" 44). Here is the backtrace: Debugger entered--Lisp error: (json-object-format ":" 44) signal(json-object-format (":" 44)) json-read-object() apply(json-read-object nil) json-read() json-read-object() apply(json-read-object nil) json-read() json-read-array() apply(json-read-array nil) json-read() json-read-object() apply(json-read-object nil) json-read() json-read-object() apply(json-read-object nil) json-read() json-partial-output("bkpt") gdb-breakpoints-list-handler-custom() gdb-breakpoints-list-handler() gdb-done-or-error("BreakpointTable=3D{nr_rows=3D\"2\"=2Cnr_cols=3D\"6\"= =2Chdr=3D[{width=3D\"7\"=2Calignment=3D\... gud-gdbmi-marker-filter("colhdr=3D\"Address\"}=2C{width=3D\"40\"=2Calignm= ent=3D\"2\"=2Ccol_name=3D\"what\"=2C... apply(gud-gdbmi-marker-filter "colhdr=3D\"Address\"}=2C{width=3D\"40\"=2C= alignment=3D\"2\"=2Ccol_name=3D\"w... gud-marker-filter("colhdr=3D\"Address\"}=2C{width=3D\"40\"=2Calignment=3D= \"2\"=2Ccol_name=3D\"what\"=2Ccolhdr... gud-filter(# "colhdr=3D\"Address\"}=2C{width=3D\"40\"= =2Calignment=3D\"2\"=2Ccol_name=3D\... The content of buffer *partial-output-emacs* is attached=2C evaluating (let ((json-array-type 'list)) (json-read)) reproduces the error. The above expression is the last one of `json-partia= l-output' in gdb-mi.el Regards=2C Guanpeng Xu _________________________________________________________________ Drag n=92 drop=97Get easy photo sharing with Windows Live=99 Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx= --_e2deff4e-24f6-406d-8616-eacd29f4fbeb_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Package: emacs
Version: 23.1.50.11

(This is the CVS HEAD version = of emacs.)

I tried M-x gdb to run emacs under gdb. =3B The comma= nd line was

 =3B gdb -i=3Dmi ~/src/emacs/src/emacs

and I = got the error '(json-object-format ":" 44). =3B Here is the backtrace:<= br>
Debugger entered--Lisp error: (json-object-format ":" 44)
 = =3B signal(json-object-format (":" 44))
 =3B json-read-object()
&= nbsp=3B apply(json-read-object nil)
 =3B json-read()
 =3B jso= n-read-object()
 =3B apply(json-read-object nil)
 =3B json-re= ad()
 =3B json-read-array()
 =3B apply(json-read-array nil) =3B json-read()
 =3B json-read-object()
 =3B apply(jso= n-read-object nil)
 =3B json-read()
 =3B json-read-object() =3B apply(json-read-object nil)
 =3B json-read()
 =3B = json-partial-output("bkpt")
 =3B gdb-breakpoints-list-handler-custom= ()
 =3B gdb-breakpoints-list-handler()
 =3B gdb-done-or-error= ("BreakpointTable=3D{nr_rows=3D\"2\"=2Cnr_cols=3D\"6\"=2Chdr=3D[{width=3D\"= 7\"=2Calignment=3D\...
 =3B gud-gdbmi-marker-filter("colhdr=3D\"Addr= ess\"}=2C{width=3D\"40\"=2Calignment=3D\"2\"=2Ccol_name=3D\"what\"=2C... =3B apply(gud-gdbmi-marker-filter "colhdr=3D\"Address\"}=2C{width=3D\= "40\"=2Calignment=3D\"2\"=2Ccol_name=3D\"w...
 =3B gud-marker-filter= ("colhdr=3D\"Address\"}=2C{width=3D\"40\"=2Calignment=3D\"2\"=2Ccol_name=3D= \"what\"=2Ccolhdr...
 =3B gud-filter(#<=3Bprocess gud-emacs>=3B = "colhdr=3D\"Address\"}=2C{width=3D\"40\"=2Calignment=3D\"2\"=2Ccol_name=3D\= ...

The content of buffer *partial-output-emacs* is attached=2C eval= uating

 =3B (let ((json-array-type 'list)) (json-read))

r= eproduces the error. =3B The above expression is the last one of `json-= partial-output'
in gdb-mi.el

Regards=2C
Guanpeng Xu

<= hr />What can you do with the new Windows Live? Find out = --_e2deff4e-24f6-406d-8616-eacd29f4fbeb_-- --_848dc0c8-68f9-4201-8f64-e853ada3301d_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="json-data" eyJCcmVha3BvaW50VGFibGUiOnsibnJfcm93cyI6IjIiLCJucl9jb2xzIjoiNiIsImhkciI6W3si d2lkdGgiOiI3IiwiYWxpZ25tZW50IjoiLTEiLCJjb2xfbmFtZSI6Im51bWJlciIsImNvbGhkciI6 Ik51bSJ9LHsid2lkdGgiOiIxNCIsImFsaWdubWVudCI6Ii0xIiwiY29sX25hbWUiOiJ0eXBlIiwi Y29saGRyIjoiVHlwZSJ9LHsid2lkdGgiOiI0IiwiYWxpZ25tZW50IjoiLTEiLCJjb2xfbmFtZSI6 ImRpc3AiLCJjb2xoZHIiOiJEaXNwIn0seyJ3aWR0aCI6IjMiLCJhbGlnbm1lbnQiOiItMSIsImNv bF9uYW1lIjoiZW5hYmxlZCIsImNvbGhkciI6IkVuYiJ9LHsid2lkdGgiOiIxOCIsImFsaWdubWVu dCI6Ii0xIiwiY29sX25hbWUiOiJhZGRyIiwiY29saGRyIjoiQWRkcmVzcyJ9LHsid2lkdGgiOiI0 MCIsImFsaWdubWVudCI6IjIiLCJjb2xfbmFtZSI6IndoYXQiLCJjb2xoZHIiOiJXaGF0In1dLCJi b2R5IjpbeyJudW1iZXIiOiIxIiwidHlwZSI6ImJyZWFrcG9pbnQiLCJkaXNwIjoia2VlcCIsImVu YWJsZWQiOiJ5IiwiYWRkciI6IjB4MDAwMDAwMDAwMDRhNTZiZCIsImZ1bmMiOiJhYm9ydCIsImZp bGUiOiJlbWFjcy5jIiwiZnVsbG5hbWUiOiIvaG9tZS94Z3Avc3JjL2VtYWNzL3NyYy9lbWFjcy5j IiwibGluZSI6IjQzMyIsInRpbWVzIjoiMCJ9LHsibnVtYmVyIjoiMiIsInR5cGUiOiJicmVha3Bv aW50IiwiZGlzcCI6ImRlbCIsImVuYWJsZWQiOiJ5IiwiYWRkciI6IjB4MDAwMDAwMDAwMDRjN2Nh YiIsImZ1bmMiOiJpbml0X3N5c19tb2RlcyIsImZpbGUiOiJzeXNkZXAuYyIsImZ1bGxuYW1lIjoi L2hvbWUveGdwL3NyYy9lbWFjcy9zcmMvc3lzZGVwLmMiLCJsaW5lIjoiMTEzMiIsInRpbWVzIjoi MCIsInNjcmlwdCI6eyJzaWxlbnQiLCJ4Z2V0cHRyIFZpbml0aWFsX3dpbmRvd19zeXN0ZW0iLCJz ZXQgJHRlbSA9IChzdHJ1Y3QgTGlzcF9TeW1ib2wgKikgJHB0ciIsInhnZXRwdHIgJHRlbS0+eG5h bWUiLCJzZXQgJHRlbSA9IChzdHJ1Y3QgTGlzcF9TdHJpbmcgKikgJHB0ciIsInNldCAkdGVtID0g KGNoYXIgKikgJHRlbS0+ZGF0YSIsImlmICR0ZW1bMF0gPT0gJ3gnICYmICR0ZW1bMV0gPT0gJ1ww JyIsImJyZWFrIHhfZXJyb3JfcXVpdHRlciIsImVuZCIsImNvbnRpbnVlIn19XX19 --_848dc0c8-68f9-4201-8f64-e853ada3301d_-- From nickrob@snap.net.nz Thu Jul 9 21:39:08 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 10 Jul 2009 04:39:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.5 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6A4d3Mj022805 for ; Thu, 9 Jul 2009 21:39:05 -0700 Received: from mail.gnu.org ([199.232.76.166]:58576 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1MP7t1-0007Pz-BK for emacs-pretest-bug@gnu.org; Fri, 10 Jul 2009 00:39:03 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1MP7sy-0002vT-W3 for emacs-pretest-bug@gnu.org; Fri, 10 Jul 2009 00:39:02 -0400 Received: from viper.snap.net.nz ([202.37.101.25]:42766) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MP7sy-0002v7-If for emacs-pretest-bug@gnu.org; Fri, 10 Jul 2009 00:39:00 -0400 Received: from totara (120.61.255.123.dynamic.snap.net.nz [123.255.61.120]) by viper.snap.net.nz (Postfix) with ESMTP id E05973DA01E; Fri, 10 Jul 2009 16:38:54 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id 98796C159; Fri, 10 Jul 2009 16:38:53 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19030.50653.596678.409475@totara.tehura.co.nz> Date: Fri, 10 Jul 2009 16:38:53 +1200 To: Herbert Euler , 3794@debbugs.gnu.org Cc: emacs-pretest-bug@gnu.org, dima@sphinx.net.ru Subject: bug#3794: Error in json from gdb-ui In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.2.1 From: nickrob@snap.net.nz (Nick Roberts) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Herbert Euler writes: > > Package: emacs > Version: 23.1.50.11 I think this should really go to emacs-pretest-bug@gnu.org as this is an unreleased version of Emacs. I think that works if you prefix the subject header with "23.1.50; " or use M-x report-emacs-bug in the Emacs version which has the bug. > (This is the CVS HEAD version of emacs.) > > I tried M-x gdb to run emacs under gdb. The command line was > > gdb -i=mi ~/src/emacs/src/emacs > > and I got the error '(json-object-format ":" 44). Here is the backtrace: > > Debugger entered--Lisp error: (json-object-format ":" 44) > signal(json-object-format (":" 44)) > json-read-object() > apply(json-read-object nil) > json-read() > ... This relates to Dmitry Dzhus's recent changes, so I'm cc'ing him. -- Nick http://www.inet.net.nz/~nickrob From dima@sphinx.net.ru Fri Jul 10 06:28:58 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 10 Jul 2009 13:28:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, IMPRONONCABLE_2,MURPHY_DRUGS_REL8,WWWRU autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6ADSrui014400 for ; Fri, 10 Jul 2009 06:28:54 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPG9k-0000tn-F5 for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2009 09:28:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPG9W-0000fy-6U for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2009 09:28:52 -0400 Received: from [199.232.76.173] (port=46998 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPG9W-0000fs-3M for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2009 09:28:38 -0400 Received: from sphinx.net.ru ([82.146.58.194]:49930) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MPG9V-0001D2-AX for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2009 09:28:37 -0400 Received: from blizzard (95-24-188-80.broadband.corbina.ru [95.24.188.80]) (authenticated bits=0) by sphinx.net.ru (8.14.3/8.14.2) with ESMTP id n6ADSIiX090244; Fri, 10 Jul 2009 17:28:19 +0400 (MSD) (envelope-from dima@sphinx.net.ru) From: Dmitry Dzhus To: Herbert Euler Cc: 3794@debbugs.gnu.org, Cc: Nick Roberts Subject: Re: bug#3794: Error in json from gdb-ui References: Date: Fri, 10 Jul 2009 17:26:37 +0400 In-Reply-To: (Herbert Euler's message of "Thu, 9 Jul 2009 20:14:27 +0800") Message-ID: <87r5wosm7m.fsf@sphinx.net.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) --=-=-= > I tried M-x gdb to run emacs under gdb. The command line was > > gdb -i=mi ~/src/emacs/src/emacs > > and I got the error '(json-object-format ":" 44). Here is the backtrace: Thank you for reporting this bug. I could reproduce your problem and I wrote a workaround which fixes the bug for me. Could you please try the attached patch for gdb-mi.el? --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=gdb-mi-breakpoint-script-fix.patch diff -r 36335b2a0438 -r 392a117f6afc gdb-mi.el --- a/gdb-mi.el Fri Jul 10 14:57:26 2009 +0400 +++ b/gdb-mi.el Fri Jul 10 16:52:55 2009 +0400 @@ -1570,7 +1570,7 @@ (with-current-buffer (gdb-get-buffer-create 'gdb-partial-output-buffer) (erase-buffer))) -(defun json-partial-output (&optional fix-key) +(defun json-partial-output (&optional fix-key fix-list) "Parse gdb-partial-output-buffer with `json-read'. If FIX-KEY is non-nil, strip all \"FIX-KEY=\" occurences from @@ -1579,15 +1579,37 @@ -break-info are examples of MI commands which issue such responses. +If FIX-LIST is non-nil, \"FIX-LIST={..}\" is replaced with +\"FIX-LIST=[..]\" prior to parsing. This is used to fix broken +-break-info output when it contains breakpoint script field +incompatible with GDB/MI output syntax. + Note that GDB/MI output syntax is different from JSON both cosmetically and (in some cases) structurally, so correct results are not guaranteed." (with-current-buffer (gdb-get-buffer-create 'gdb-partial-output-buffer) (goto-char (point-min)) - (while (re-search-forward (concat "[\\[,]\\(" fix-key "=\\)") nil t) - (replace-match "" nil nil nil 1)) - (goto-char (point-min)) - (insert "{") + (when fix-key + (save-excursion + (while (re-search-forward (concat "[\\[,]\\(" fix-key "=\\)") nil t) + (replace-match "" nil nil nil 1)))) + (when fix-list + (save-excursion + ;; Find positions of brackets which enclose broken list + (while (re-search-forward (concat fix-list "={\"") nil t) + (let ((p1 (goto-char (- (point) 2))) + (p2 (progn (forward-sexp) + (1- (point))))) + ;; Replace braces with brackets + (save-excursion + (goto-char p1) + (delete-char 1) + (insert "[") + (goto-char p2) + (delete-char 1) + (insert "]")))))) + (goto-char (point-min)) + (insert "{") ;; Wrap field names in double quotes and replace equal sign with ;; semicolon. ;; TODO: This breaks badly with foo= inside constants @@ -1691,7 +1713,7 @@ (defun gdb-breakpoints-list-handler-custom () (let ((breakpoints-list (gdb-get-field - (json-partial-output "bkpt") + (json-partial-output "bkpt" "script") 'BreakpointTable 'body))) (setq gdb-breakpoints-list nil) (insert "Num\tType\t\tDisp\tEnb\tHits\tAddr What\n") --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Background information: That's one of the GDB/MI syntax inconsistencies coming up in this case. The problem is caused by a script being attached to `init_sys_modes` breakpoint in `.gdbinit`. When GDB/MI includes script information in `-break-info`, it violates its own syntax by wrapping script field value in curly braces (like for tuples) instead of brackets (like for lists, which should be the case for script listing), for example: script=3D{"silent","xgetptr Vinitial_window_system","set $tem =3D ( struct Lisp_Symbol *) $ptr","xgetptr $tem->xname","set $tem =3D (struct Lisp_String *) $ptr","set $tem =3D (char *) $tem->data","if $tem[0] =3D=3D = 'x' && $tem[1] =3D=3D '\0'","break x_error_quitter","end","continue"} Whereas according to GDB/MI Output Syntax tuples (enclosed in {}) may contain only variable=3Dvalue pairs. As the result, the JSON parser used in gdb-mi.el chokes. We handle this nasty case by turning `script` value into what it's meant to be, which is a list, by replacing { -> [ and ] -> }. --=20 Happy Hacking. http://sphinx.net.ru =E3=82=80 --=-=-=-- From rgm@gnu.org Fri Jul 10 20:05:01 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 11 Jul 2009 03:05:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-8.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6B34vsU022641 for <3794@emacsbugs.donarmstrong.com>; Fri, 10 Jul 2009 20:04:58 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MPStS-0005pp-KS; Fri, 10 Jul 2009 23:04:54 -0400 From: Glenn Morris To: Nick Roberts Cc: 3794@debbugs.gnu.org, Herbert Euler , dima@sphinx.net.ru Subject: Re: bug#3794: Error in json from gdb-ui References: <19030.50653.596678.409475@totara.tehura.co.nz> X-Spook: Albright argus infowar encryption Mena eavesdropping X-Ran: Z<[AZMvy?lO4n3{lW0A_fM{M*1OJy'mM|X-:FQ._:q6'w'",0>}1?g`d9bq^vQ8vBdleVX X-Hue: white X-Debbugs-No-Ack: yes X-Attribution: GM Date: Fri, 10 Jul 2009 23:04:54 -0400 Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Nick Roberts wrote: > I think this should really go to emacs-pretest-bug@gnu.org as this > is an unreleased version of Emacs. For some time now, that address has been totally equivalent to bug-gnu-emacs. cc'ing it after a bug has been filed just creates duplicate emails. > I think that works if you prefix the subject header with "23.1.50; " > or use M-x report-emacs-bug in the Emacs version which has the bug. The subject prefix does nothing. M-x report-emacs-bug would send it to emacs-pretest-bug, but as I said that makes no difference as to where it ends up. From herberteuler@hotmail.com Mon Jul 13 18:59:02 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 14 Jul 2009 01:59:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.2 required=4.0 tests=AWL,HAS_BUG_NUMBER,HTML_NBSP, MULTALT,MURPHY_DRUGS_REL8,PHONENUMBER,WWWRU autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from bay0-omc3-s9.bay0.hotmail.com (bay0-omc3-s9.bay0.hotmail.com [65.54.246.209]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6E1wvQ7006954 for <3794@emacsbugs.donarmstrong.com>; Mon, 13 Jul 2009 18:58:58 -0700 Received: from BAY143-W18 ([65.55.154.53]) by bay0-omc3-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 18:58:52 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ba64882c-aba6-4a4a-90f7-9cac7f24e597_" X-Originating-IP: [124.127.101.0] From: Herbert Euler To: CC: <3794@debbugs.gnu.org>, , Nick Roberts , Subject: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] Date: Tue, 14 Jul 2009 09:58:51 +0800 Importance: Normal In-Reply-To: <87r5wosm7m.fsf@sphinx.net.ru> References: <87r5wosm7m.fsf@sphinx.net.ru> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2009 01:58:52.0056 (UTC) FILETIME=[A2D42180:01CA0426] --_ba64882c-aba6-4a4a-90f7-9cac7f24e597_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit > From: dima@sphinx.net.ru > To: herberteuler@hotmail.com > CC: 3794@emacsbugs.donarmstrong.com; bug-gnu-emacs@gnu.org > CC: nickrob@snap.net.nz > Subject: Re: bug#3794: Error in json from gdb-ui > Date: Fri, 10 Jul 2009 17:26:37 +0400 > > > > I tried M-x gdb to run emacs under gdb. The command line was > > > > gdb -i=mi ~/src/emacs/src/emacs > > > > and I got the error '(json-object-format ":" 44). Here is the backtrace: > > Thank you for reporting this bug. > > I could reproduce your problem and I wrote a workaround which fixes the > bug for me. Could you please try the attached patch for gdb-mi.el? That patch works for me, too. Thanks. But here are some other problems: 1. When there's file .gdbinit in the directory of the debugged program, and there're breakpoints in that file, M-x gdb showed those breakpoints after started previously, while the new implementation doesn't, unless requesting them explicitly with "info b". 2. The command "shell" is broken: In M-x gdb, shell ps aux | grep emacs results in no output; but in a "real" gdb, the output looks like this: shell ps aux | grep emacs &"shell ps aux | grep emacs\n" xgp 4886 1.3 0.1 80796 25900 pts/1 T 09:38 0:08 emacs xgp 4936 0.3 0.1 77688 22568 pts/10 T+ 09:39 0:02 ./emacs xgp 5209 0.0 0.1 28128 16548 pts/6 Ss+ 09:46 0:00 /usr/local/bin/gdb -i=mi emacs xgp 5353 0.4 0.1 28184 16584 pts/1 S+ 09:49 0:00 gdb -i=mi emacs xgp 5354 0.0 0.0 52800 976 pts/1 S+ 09:49 0:00 bash -c ps aux | grep emacs xgp 5356 0.0 0.0 51124 688 pts/1 S+ 09:49 0:00 grep emacs ^done 3. Previously, typing directly RET at the M-x gdb prompt repeats the last command in history. This is also what a "real" gdb does. But in the new implementation, this does nothing now. As Nick said, this implementation is still in developing. Should I wait then? Regards, Guanpeng Xu _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us --_ba64882c-aba6-4a4a-90f7-9cac7f24e597_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit > From: dima@sphinx.net.ru
> To: herberteuler@hotmail.com
> CC: 3794@emacsbugs.donarmstrong.com; bug-gnu-emacs@gnu.org
> CC: nickrob@snap.net.nz
> Subject: Re: bug#3794: Error in json from gdb-ui
> Date: Fri, 10 Jul 2009 17:26:37 +0400
>
>
> > I tried M-x gdb to run emacs under gdb. The command line was
> >
> > gdb -i=mi ~/src/emacs/src/emacs
> >
> > and I got the error '(json-object-format ":" 44). Here is the backtrace:
>
> Thank you for reporting this bug.
>
> I could reproduce your problem and I wrote a workaround which fixes the
> bug for me. Could you please try the attached patch for gdb-mi.el?

That patch works for me, too.  Thanks.

But here are some other problems:

1. When there's file .gdbinit in the directory of the debugged
program, and there're breakpoints in that file, M-x gdb showed those
breakpoints after started previously, while the new implementation
doesn't, unless requesting them explicitly with "info b".

2. The command "shell" is broken: In M-x gdb,

     shell ps aux | grep emacs

results in no output; but in a "real" gdb, the output looks like this:

     shell ps aux | grep emacs
     &"shell ps aux | grep emacs\n"
     xgp   4886  1.3  0.1 80796 25900 pts/1   T    09:38   0:08 emacs
     xgp   4936  0.3  0.1 77688 22568 pts/10  T+   09:39   0:02 ./emacs
     xgp   5209  0.0  0.1 28128 16548 pts/6   Ss+  09:46   0:00 /usr/local/bin/gdb -i=mi emacs
     xgp   5353  0.4  0.1 28184 16584 pts/1   S+   09:49   0:00 gdb -i=mi emacs
     xgp   5354  0.0  0.0 52800  976 pts/1    S+   09:49   0:00 bash -c ps aux | grep emacs
     xgp   5356  0.0  0.0 51124  688 pts/1    S+   09:49   0:00 grep emacs
     ^done

3. Previously, typing directly RET at the M-x gdb prompt repeats the
last command in history.  This is also what a "real" gdb does.  But
in the new implementation, this does nothing now.

As Nick said, this implementation is still in developing.  Should I
wait then?

Regards,
Guanpeng Xu

Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! --_ba64882c-aba6-4a4a-90f7-9cac7f24e597_-- From dima@sphinx.net.ru Tue Jul 14 06:47:04 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 14 Jul 2009 13:47:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.5 required=4.0 tests=HAS_BUG_NUMBER,IMPRONONCABLE_2, MURPHY_DRUGS_REL8,PHONENUMBER,SPF_HELO_PASS,WWWRU autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from sphinx.net.ru (sphinx.net.ru [82.146.58.194]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6EDkwsd030116 for <3794@emacsbugs.donarmstrong.com>; Tue, 14 Jul 2009 06:47:00 -0700 Received: from blizzard (93-81-184-65.broadband.corbina.ru [93.81.184.65]) (authenticated bits=0) by sphinx.net.ru (8.14.3/8.14.2) with ESMTP id n6EDkrmn074809; Tue, 14 Jul 2009 17:46:54 +0400 (MSD) (envelope-from dima@sphinx.net.ru) From: Dmitry Dzhus To: Herbert Euler Cc: <3794@debbugs.gnu.org>, , Nick Roberts Cc: dima@sphinx.net.ru Subject: Re: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] References: <87r5wosm7m.fsf@sphinx.net.ru> Date: Tue, 14 Jul 2009 17:46:28 +0400 In-Reply-To: (Herbert Euler's message of "Tue, 14 Jul 2009 09:58:51 +0800") Message-ID: <87zlb71iob.fsf@sphinx.net.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Herbert Euler wrote: >> > I tried M-x gdb to run emacs under gdb. The command line was >> > >> > gdb -i=mi ~/src/emacs/src/emacs >> > >> > and I got the error '(json-object-format ":" 44). Here is the backtrace: >> >> I could reproduce your problem and I wrote a workaround which fixes the >> bug for me. Could you please try the attached patch for gdb-mi.el? > > That patch works for me, too. Thanks. It's in the trunk now. > 2. The command "shell" is broken: In M-x gdb, > > shell ps aux | grep emacs > > results in no output; but in a "real" gdb, the output looks like this: > > shell ps aux | grep emacs > &"shell ps aux | grep emacs\n" > xgp 4886 1.3 0.1 80796 25900 pts/1 T 09:38 0:08 emacs > xgp 4936 0.3 0.1 77688 22568 pts/10 T+ 09:39 0:02 ./emacs > xgp 5209 0.0 0.1 28128 16548 pts/6 Ss+ 09:46 0:00 /usr/local/bin/gdb -i=mi emacs > xgp 5353 0.4 0.1 28184 16584 pts/1 S+ 09:49 0:00 gdb -i=mi emacs > xgp 5354 0.0 0.0 52800 976 pts/1 S+ 09:49 0:00 bash -c ps aux | grep emacs > xgp 5356 0.0 0.0 51124 688 pts/1 S+ 09:49 0:00 grep emacs > ^done Output of GDB's shell command goes as is straight to the terminal without being prefixed by stream identifier (~, @, & etc.) Thus it's harder to distinguish where this output should go (to GUD buffer, to MI parser etc.) I managed to produce a small patch which does the trick for simple shell commands like yours, but don't expect it to work with `top(1)` for example. I've attached the patch. Let me know if you notice that it breaks something. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=gdb-shell.patch Content-Description: Print shell command output in GUD buffer (gdbmi-record-list, gdb-shell): Redirect shell command output to GUD buffer (Emacs bug #3794) diff -r 3ba511c84066 gdb-mi.el --- a/gdb-mi.el +++ b/gdb-mi.el @@ -1418,7 +1418,8 @@ (gdb-stopped . "\\*stopped,?\\(.*?\n\\)") (gdb-running . "\\*running,\\(.*?\n\\)") (gdb-thread-created . "=thread-created,\\(.*?\n\\)") - (gdb-thread-exited . "=thread-exited,\\(.*?\n\\)"))) + (gdb-thread-exited . "=thread-exited,\\(.*?\n\\)") + (gdb-shell . "\\(\\(?:^.+\n\\)+\\)"))) (defun gud-gdbmi-marker-filter (string) "Filter GDB/MI output." @@ -1476,7 +1477,10 @@ gdb-filter-output)) (defun gdb-gdb (output-field)) - +(defun gdb-shell (output-field) + (let ((gdb-output-sink gdb-output-sink)) + (setq gdb-filter-output + (concat output-field gdb-filter-output)))) ;; gdb-invalidate-threads is defined to accept 'update-threads signal (defun gdb-thread-created (output-field)) (defun gdb-thread-exited (output-field) --=-=-= > 3. Previously, typing directly RET at the M-x gdb prompt repeats the > last command in history. This is also what a "real" gdb does. But in > the new implementation, this does nothing now. I've fixed the code which mimicks RET behaviour for GUD buffer. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=gdb-send-ret.patch Content-Description: Repeat last command on RET properly (gdb-send): Repeat last command on RET properly (Emacs bug #3794). diff -r b45e93199252 gdb-mi.el --- a/gdb-mi.el +++ b/gdb-mi.el @@ -1267,7 +1267,7 @@ (let ((inhibit-read-only t)) (remove-text-properties (point-min) (point-max) '(face)))) ;; mimic key to repeat previous command in GDB - (if (not (string-match "^\\s+$" string)) + (if (not (string= "" string)) (setq gdb-last-command string) (if gdb-last-command (setq string gdb-last-command))) (if gdb-enable-debug --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > As Nick said, this implementation is still in developing. Should I > wait then? It's GSoC project, see http://emacswiki.org/emacs/GDB-MI/ for some details. Don't wait, report bugs of Emacs trunk version as soon as you encounter them, but _please_ file *different* reports for different bugs. I first put really bleeding changes to my Mercurial repo, then commit them to Emacs upstream for further testing. Non-stop debugging support will hit the trunk by the end of this week. --=20 Happy Hacking. http://sphinx.net.ru =E3=82=80 --=-=-=-- From rgm@gnu.org Tue Jul 21 19:58:19 2009 Received: (at control) by emacsbugs.donarmstrong.com; 22 Jul 2009 02:58:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,ONEWORD autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6M2wF0x006093 for ; Tue, 21 Jul 2009 19:58:17 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MTS23-0004iN-1r; Tue, 21 Jul 2009 22:58:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19046.32838.974527.846560@fencepost.gnu.org> Date: Tue, 21 Jul 2009 22:58:14 -0400 From: Glenn Morris To: control Subject: control merge 3794 3840 severity 3887 wishlist reassign 3854 emacs,ns severity 3883 minor close 1528 close 1225 From herberteuler@hotmail.com Fri Jul 31 01:06:56 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 31 Jul 2009 08:06:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.1 required=4.0 tests=AWL,HAS_BUG_NUMBER,MULTALT, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from bay0-omc3-s18.bay0.hotmail.com (bay0-omc3-s18.bay0.hotmail.com [65.54.246.218]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6V86mJ1006533 for <3794@emacsbugs.donarmstrong.com>; Fri, 31 Jul 2009 01:06:49 -0700 Received: from BAY143-W20 ([65.55.154.55]) by bay0-omc3-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 01:06:42 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_dba245ff-2338-46d8-b2e0-5a5bb1500709_" X-Originating-IP: [124.127.101.0] From: Herbert Euler To: CC: <3794@debbugs.gnu.org>, , Nick Roberts Subject: RE: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] Date: Fri, 31 Jul 2009 16:06:42 +0800 Importance: Normal In-Reply-To: <87zlb71iob.fsf@sphinx.net.ru> References: <87r5wosm7m.fsf@sphinx.net.ru> <87zlb71iob.fsf@sphinx.net.ru> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jul 2009 08:06:42.0615 (UTC) FILETIME=[D6EDEC70:01CA11B5] --_dba245ff-2338-46d8-b2e0-5a5bb1500709_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm so sorry for the big delay. I was not able to use computers these days. > > 2. The command "shell" is broken: In M-x gdb=2C > > > > shell ps aux | grep emacs > > > > results in no output=3B but in a "real" gdb=2C the output looks like th= is: > > > > shell ps aux | grep emacs > > &"shell ps aux | grep emacs\n" > > xgp 4886 1.3 0.1 80796 25900 pts/1 T 09:38 0:08 emacs > > xgp 4936 0.3 0.1 77688 22568 pts/10 T+ 09:39 0:02 ./emacs > > xgp 5209 0.0 0.1 28128 16548 pts/6 Ss+ 09:46 0:00 /usr/local/bin/gdb -i= =3Dmi emacs > > xgp 5353 0.4 0.1 28184 16584 pts/1 S+ 09:49 0:00 gdb -i=3Dmi emacs > > xgp 5354 0.0 0.0 52800 976 pts/1 S+ 09:49 0:00 bash -c ps aux | grep em= acs > > xgp 5356 0.0 0.0 51124 688 pts/1 S+ 09:49 0:00 grep emacs > > ^done > > Output of GDB's shell command goes as is straight to the terminal > without being prefixed by stream identifier (~=2C @=2C & etc.) Thus it's > harder to distinguish where this output should go (to GUD buffer=2C to MI > parser etc.) I managed to produce a small patch which does the trick for > simple shell commands like yours=2C but don't expect it to work with > `top(1)` for example. I've attached the patch. Let me know if you notice > that it breaks something. I see. The patch works very well. I got an idea of how to catch the output of `top(1)': Setting up the gud buffer to make it behave like a shell buffer temporarily during the execution of the `shell' command=2C and switching back to make it behave in the gdb way after seen `^done'. However=2C this seems not to be worthy implementing=2C because normally only simple shell commands are executed via the `shell' command. > > 3. Previously=2C typing directly RET at the M-x gdb prompt repeats the > > last command in history. This is also what a "real" gdb does. But in > > the new implementation=2C this does nothing now. > > I've fixed the code which mimicks RET behaviour for GUD buffer. It works for me=2C thank you. And here's another three problems: 4. Killing a gdb buffer won't send the `detach' command to the gdb process=2C leaving the debugged process permentally being stopped. This is often unconvenient. 5. The commands like `while' and `if' cannot be handled correctly. Combined with problem #4=2C this leads to a bad use case: After typing such a command=2C the gdb process hangs=2C so the gdb buffer has to be killed. Then=2C the debugged process hangs and has to be killed. As a result=2C both the debugger and the debugged process have to be restarted. 6. Completion should be done with the emacs completion feature=2C i.e. try-completion=2C completing-read etc. Regards=2C Guanpeng Xu _________________________________________________________________ More than messages=96check out the rest of the Windows Live=99. http://www.microsoft.com/windows/windowslive/= --_dba245ff-2338-46d8-b2e0-5a5bb1500709_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm so sorry for the big delay. =3B I was not able to use computers the= se
days.

>=3B >=3B 2. The command "shell" is broken: In M-x g= db=2C
>=3B >=3B
>=3B >=3B shell ps aux | grep emacs
>=3B= >=3B
>=3B >=3B results in no output=3B but in a "real" gdb=2C the= output looks like this:
>=3B >=3B
>=3B >=3B shell ps aux | g= rep emacs
>=3B >=3B &=3B"shell ps aux | grep emacs\n"
>=3B &= gt=3B xgp 4886 1.3 0.1 80796 25900 pts/1 T 09:38 0:08 emacs
>=3B >= =3B xgp 4936 0.3 0.1 77688 22568 pts/10 T+ 09:39 0:02 ./emacs
>=3B >= =3B xgp 5209 0.0 0.1 28128 16548 pts/6 Ss+ 09:46 0:00 /usr/local/bin/gdb -i= =3Dmi emacs
>=3B >=3B xgp 5353 0.4 0.1 28184 16584 pts/1 S+ 09:49 0:= 00 gdb -i=3Dmi emacs
>=3B >=3B xgp 5354 0.0 0.0 52800 976 pts/1 S+ 0= 9:49 0:00 bash -c ps aux | grep emacs
>=3B >=3B xgp 5356 0.0 0.0 511= 24 688 pts/1 S+ 09:49 0:00 grep emacs
>=3B >=3B ^done
>=3B
&= gt=3B Output of GDB's shell command goes as is straight to the terminal
= >=3B without being prefixed by stream identifier (~=2C @=2C &=3B etc.)= Thus it's
>=3B harder to distinguish where this output should go (to = GUD buffer=2C to MI
>=3B parser etc.) I managed to produce a small pat= ch which does the trick for
>=3B simple shell commands like yours=2C b= ut don't expect it to work with
>=3B `top(1)` for example. I've attach= ed the patch. Let me know if you notice
>=3B that it breaks something.=

I see. =3B The patch works very well.

I got an idea of h= ow to catch the output of `top(1)': Setting up the
gud buffer to make it= behave like a shell buffer temporarily during
the execution of the `she= ll' command=2C and switching back to make it
behave in the gdb way after= seen `^done'. =3B However=2C this seems not to
be worthy implementi= ng=2C because normally only simple shell commands
are executed via the `= shell' command.

>=3B >=3B 3. Previously=2C typing directly RET a= t the M-x gdb prompt repeats the
>=3B >=3B last command in history. = This is also what a "real" gdb does. But in
>=3B >=3B the new implem= entation=2C this does nothing now.
>=3B
>=3B I've fixed the code = which mimicks RET behaviour for GUD buffer.

It works for me=2C thank= you.

And here's another three problems:

4. Killing a gdb buf= fer won't send the `detach' command to the gdb
process=2C leaving the de= bugged process permentally being stopped. =3B This
is often unconven= ient.

5. The commands like `while' and `if' cannot be handled correc= tly.
Combined with problem #4=2C this leads to a bad use case: After typ= ing
such a command=2C the gdb process hangs=2C so the gdb buffer has to = be
killed. =3B Then=2C the debugged process hangs and has to be kill= ed. =3B As a
result=2C both the debugger and the debugged process ha= ve to be
restarted.

6. Completion should be done with the emacs c= ompletion feature=2C
i.e. try-completion=2C completing-read etc.

= Regards=2C
Guanpeng Xu


check out the rest of the Wind= ows Live=99. More than mail=96Windows Live=99 goes way beyond your inbox. = More than messages = --_dba245ff-2338-46d8-b2e0-5a5bb1500709_-- From dima@sphinx.net.ru Tue Aug 4 11:43:00 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 4 Aug 2009 18:43:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,SPF_HELO_PASS,WWWRU autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from sphinx.net.ru (sphinx.net.ru [82.146.58.194]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n74Igthh005669 for <3794@emacsbugs.donarmstrong.com>; Tue, 4 Aug 2009 11:42:57 -0700 Received: from blizzard (95-24-214-72.broadband.corbina.ru [95.24.214.72]) (authenticated bits=0) by sphinx.net.ru (8.14.3/8.14.2) with ESMTP id n74IgphL042648; Tue, 4 Aug 2009 22:42:51 +0400 (MSD) (envelope-from dima@sphinx.net.ru) From: Dmitry Dzhus To: Herbert Euler Cc: <3794@debbugs.gnu.org>, , Nick Roberts Cc: dima@sphinx.net.ru Subject: Re: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] References: <87r5wosm7m.fsf@sphinx.net.ru> <87zlb71iob.fsf@sphinx.net.ru> Date: Tue, 04 Aug 2009 22:40:19 +0400 In-Reply-To: (Herbert Euler's message of "Fri, 31 Jul 2009 16:06:42 +0800") Message-ID: <87my6fv2wc.fsf@sphinx.net.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Herbert Euler wrote: > I see. The patch works very well. Shell patch is in the trunk now. >> > 3. Previously, typing directly RET at the M-x gdb prompt repeats the >> > last command in history. This is also what a "real" gdb does. But in >> > the new implementation, this does nothing now. >> >> I've fixed the code which mimicks RET behaviour for GUD buffer. > > It works for me, thank you. RET behaviour patch is in the trunk now. > 6. Completion should be done with the emacs completion feature, > i.e. try-completion, completing-read etc. Do you mean the completion of commands in GUD buffer? --=20 Happy Hacking. http://sphinx.net.ru =E3=82=80 From herberteuler@hotmail.com Wed Aug 5 19:20:30 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 6 Aug 2009 02:20:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=AWL,HAS_BUG_NUMBER,HTML_NBSP, MULTALT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from bay0-omc3-s26.bay0.hotmail.com (bay0-omc3-s26.bay0.hotmail.com [65.54.246.226]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n762KTkh021540 for <3794@emacsbugs.donarmstrong.com>; Wed, 5 Aug 2009 19:20:30 -0700 Received: from BAY143-W13 ([65.55.154.48]) by bay0-omc3-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 19:20:23 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a55502a4-dab1-4c33-85f7-8956f6ebd13f_" X-Originating-IP: [124.127.101.0] From: Herbert Euler To: CC: <3794@debbugs.gnu.org>, , Nick Roberts Subject: RE: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] Date: Thu, 6 Aug 2009 10:20:23 +0800 Importance: Normal In-Reply-To: <87my6fv2wc.fsf@sphinx.net.ru> References: <87r5wosm7m.fsf@sphinx.net.ru> <87zlb71iob.fsf@sphinx.net.ru> <87my6fv2wc.fsf@sphinx.net.ru> MIME-Version: 1.0 X-OriginalArrivalTime: 06 Aug 2009 02:20:23.0471 (UTC) FILETIME=[7412ABF0:01CA163C] --_a55502a4-dab1-4c33-85f7-8956f6ebd13f_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit > > 6. Completion should be done with the emacs completion feature, > > i.e. try-completion, completing-read etc. > > Do you mean the completion of commands in GUD buffer? Yes. Currently, completion behaves like this (the vertical bar `|' indicates the cursor): (gdb) b redis| ;; Hit TAB. b redisplay_dont_pause b redisplay_interface b redisplay_internal b redisplay_mode_lines b redisplay_performed_directly_p b redisplay_preserve_echo_area b redisplay_window b redisplay_window_0 b redisplay_window_1 b redisplay_window_error b redisplay_windows b redisplaying_p (gdb) b redisplay | ;; There is an extra space character ;; after `redisplay'. This seems to ;; be due to `redisplay' being an ;; available completion. Previously, completion in gdb is done this way: (gdb) b redis| ;; Hit TAB. (gdb) b redisplay| ;; The first time TAB is hit, ;; completes to that match. (gdb) b redisplay| ;; Hit TAB again. (gdb) b redisplay| ;; And the *Completions* window is ;; popped up to show all available ;; completions. At that point, the user can type RET to accept `redisplay' as the match, or type more characters and then try other completions. Regards, Guanpeng Xu _________________________________________________________________ Share your memories online with anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1 --_a55502a4-dab1-4c33-85f7-8956f6ebd13f_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit > > 6. Completion should be done with the emacs completion feature,
> > i.e. try-completion, completing-read etc.
>
> Do you mean the completion of commands in GUD buffer?

Yes.  Currently, completion behaves like this (the vertical bar `|'
indicates the cursor):

(gdb) b redis|                  ;; Hit TAB.
b redisplay_dont_pause
b redisplay_interface
b redisplay_internal
b redisplay_mode_lines
b redisplay_performed_directly_p
b redisplay_preserve_echo_area
b redisplay_window
b redisplay_window_0
b redisplay_window_1
b redisplay_window_error
b redisplay_windows
b redisplaying_p
(gdb) b redisplay |             ;; There is an extra space character
                                ;; after `redisplay'.  This seems to
                ;; be due to `redisplay' being an
                ;; available completion.

Previously, completion in gdb is done this way:

(gdb) b redis|                  ;; Hit TAB.
(gdb) b redisplay|              ;; The first time TAB is hit,
                                ;; completes to that match.
(gdb) b redisplay|              ;; Hit TAB again.
(gdb) b redisplay|              ;; And the *Completions* window is
                                ;; popped up to show all available
                ;; completions.

At that point, the user can type RET to accept `redisplay' as the
match, or type more characters and then try other completions.

Regards,
Guanpeng Xu

Share your memories online with anyone you want anyone you want. --_a55502a4-dab1-4c33-85f7-8956f6ebd13f_-- From herberteuler@hotmail.com Wed Aug 5 19:29:15 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 6 Aug 2009 02:29:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL,HAS_BUG_NUMBER,MULTALT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from bay0-omc3-s22.bay0.hotmail.com (bay0-omc3-s22.bay0.hotmail.com [65.54.246.222]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n762TDQd022077 for <3794@emacsbugs.donarmstrong.com>; Wed, 5 Aug 2009 19:29:15 -0700 Received: from BAY143-W24 ([65.55.154.59]) by bay0-omc3-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 19:29:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bbfba917-8456-4863-a0bc-3e75a336c903_" X-Originating-IP: [124.127.101.0] From: Herbert Euler To: CC: <3794@debbugs.gnu.org>, , Nick Roberts Subject: RE: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] Date: Thu, 6 Aug 2009 10:29:08 +0800 Importance: Normal In-Reply-To: <87my6fv2wc.fsf@sphinx.net.ru> References: <87r5wosm7m.fsf@sphinx.net.ru> <87zlb71iob.fsf@sphinx.net.ru> <87my6fv2wc.fsf@sphinx.net.ru> MIME-Version: 1.0 X-OriginalArrivalTime: 06 Aug 2009 02:29:08.0156 (UTC) FILETIME=[ACCF3FC0:01CA163D] --_bbfba917-8456-4863-a0bc-3e75a336c903_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit > > 6. Completion should be done with the emacs completion feature, > > i.e. try-completion, completing-read etc. > > Do you mean the completion of commands in GUD buffer? Hmmm, I misunderstood your words. Completions of command names is another feature that should be done with the emacs completion feature, but to me it is not as important as completions of other completable arguments, such as function/variable names. Regards, Guanpeng Xu _________________________________________________________________ Share your memories online with anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1 --_bbfba917-8456-4863-a0bc-3e75a336c903_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit > > 6. Completion should be done with the emacs completion feature,
> > i.e. try-completion, completing-read etc.
>
> Do you mean the completion of commands in GUD buffer?

Hmmm, I misunderstood your words.  Completions of command names
is another feature that should be done with the emacs completion feature,
but to me it is not as important as completions of other completable
arguments, such as function/variable names.

Regards,
Guanpeng Xu

Share your memories online with anyone you want anyone you want. --_bbfba917-8456-4863-a0bc-3e75a336c903_-- From rgm@gnu.org Fri Aug 7 13:30:22 2009 Received: (at control) by emacsbugs.donarmstrong.com; 7 Aug 2009 20:30:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-5.0 required=4.0 tests=AWL,ONEWORD,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n77KULon031014 for ; Fri, 7 Aug 2009 13:30:22 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MZW4w-00061B-DN; Fri, 07 Aug 2009 16:30:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19068.36570.353026.640455@fencepost.gnu.org> Date: Fri, 7 Aug 2009 16:30:18 -0400 From: Glenn Morris To: control Subject: control X-Attribution: GM X-Mailer: VM (www.wonderworks.com/vm), GNU Emacs (www.gnu.org/software/emacs) X-Hue: white X-Ran: t(,5Z",o5I@ZD6sDtvB]$6`On@c%$-Hb|?f<]xW4BVO.uKk]h)z:uu\t^%(`L<:#uRPJ"s X-Debbugs-No-Ack: yes merge 3794 3993 4035 4059 4060 merge 4065 4066 close 4028 reassign 4063 emacs,ns reassign 4070 emacs,ns From dima@sphinx.net.ru Sun Aug 16 16:15:21 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 16 Aug 2009 23:15:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, SPF_HELO_PASS,WWWRU autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from sphinx.net.ru (sphinx.net.ru [82.146.58.194]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7GNFI4C028332 for <3794@emacsbugs.donarmstrong.com>; Sun, 16 Aug 2009 16:15:20 -0700 Received: from blizzard (95-24-180-35.broadband.corbina.ru [95.24.180.35]) (authenticated bits=0) by sphinx.net.ru (8.14.3/8.14.2) with ESMTP id n7GNFEX1096929; Mon, 17 Aug 2009 03:15:15 +0400 (MSD) (envelope-from dima@sphinx.net.ru) From: Dmitry Dzhus To: Herbert Euler Cc: <3794@debbugs.gnu.org>, Nick Roberts Cc: dima@sphinx.net.ru Subject: Re: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] References: <87r5wosm7m.fsf@sphinx.net.ru> <87zlb71iob.fsf@sphinx.net.ru> Date: Mon, 17 Aug 2009 03:11:10 +0400 In-Reply-To: (Herbert Euler's message of "Fri, 31 Jul 2009 16:06:42 +0800") Message-ID: <874os7qrqp.fsf@sphinx.net.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Herbert Euler wrote: > 4. Killing a gdb buffer won't send the `detach' command to the gdb > process, leaving the debugged process permentally being stopped. This > is often unconvenient. This should be fixed in CVS now: I've changed the code so that killing GUD buffer sends `-target-detach` command to process. > 5. The commands like `while' and `if' cannot be handled correctly. > Combined with problem #4, this leads to a bad use case: After typing > such a command, the gdb process hangs, so the gdb buffer has to be > killed. Then, the debugged process hangs and has to be killed. As a > result, both the debugger and the debugged process have to be > restarted. I think that probably it will be tricky to handle with the current GUD pseudoCLI console we have. This will need further investigating. --=20 Happy Hacking. http://sphinx.net.ru =E3=82=80 From nickrob@snap.net.nz Wed Sep 9 20:46:29 2009 Received: (at 3794) by emacsbugs.donarmstrong.com; 10 Sep 2009 03:46:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from viper.snap.net.nz (viper.snap.net.nz [202.37.101.25]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8A3kSq6012751 for <3794@emacsbugs.donarmstrong.com>; Wed, 9 Sep 2009 20:46:29 -0700 Received: from totara (unknown [123.255.29.50]) by viper.snap.net.nz (Postfix) with ESMTP id 71E4E3DA2C3; Thu, 10 Sep 2009 15:46:27 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id C73D5C164; Thu, 10 Sep 2009 15:46:25 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19112.30353.787956.142066@totara.tehura.co.nz> Date: Thu, 10 Sep 2009 15:46:25 +1200 To: Herbert Euler Cc: , <3794@debbugs.gnu.org>, Subject: RE: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui] In-Reply-To: References: <87r5wosm7m.fsf@sphinx.net.ru> <87zlb71iob.fsf@sphinx.net.ru> X-Mailer: VM 7.19 under Emacs 22.2.1 From: nickrob@snap.net.nz (Nick Roberts) > 4. Killing a gdb buffer won't send the `detach' command to the gdb > process, leaving the debugged process permentally being stopped. This > is often unconvenient. I've reverted Dmitry's fix for this as detaching might not be what the user wants and it can cause problems (bug#4375: can't kill killed gud buffer). If you want to deatch the inferior you should do it manually with the GDB CLI command "detach" before killing the GUD buffer. -- Nick http://www.inet.net.nz/~nickrob From rgm@gnu.org Thu Sep 10 10:42:47 2009 Received: (at control) by emacsbugs.donarmstrong.com; 10 Sep 2009 17:42:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,ONEWORD autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8AHgkMo020451 for ; Thu, 10 Sep 2009 10:42:47 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MlnfR-0004dM-A0; Thu, 10 Sep 2009 13:42:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19113.14997.229379.374913@fencepost.gnu.org> Date: Thu, 10 Sep 2009 13:42:45 -0400 From: Glenn Morris To: control Subject: control forcemerge 3794 4389 severity 4382 wishlist reassign 4390 spam reassign 4391 spam From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 21 19:20:02 2010 Received: (at control) by debbugs.gnu.org; 22 Nov 2010 00:20:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PKK8Y-0006Nd-3s for submit@debbugs.gnu.org; Sun, 21 Nov 2010 19:20:02 -0500 Received: from pantheon-po41.its.yale.edu ([130.132.50.98]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PKK8V-0006NQ-E8 for control@debbugs.gnu.org; Sun, 21 Nov 2010 19:19:59 -0500 Received: from furball (dhcp128036014014.central.yale.edu [128.36.14.14]) (authenticated bits=0) by pantheon-po41.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id oAM0PCZd017642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 21 Nov 2010 19:25:13 -0500 Received: by furball (Postfix, from userid 1000) id 744CB1610A5; Sun, 21 Nov 2010 19:25:11 -0500 (EST) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 3794 Date: Sun, 21 Nov 2010 19:25:11 -0500 Message-ID: <87r5eep5lk.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) close 3794 thanks From unknown Sat Jun 21 10:43:49 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 20 Dec 2010 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator