From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Damien Mattei Newsgroups: gmane.lisp.guile.devel Subject: Re: A Guile debugger workgroup? Date: Tue, 29 Nov 2022 21:18:23 +0100 Message-ID: References: <87edtlptgv.fsf@laura> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004b097805eea1b19c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37541"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org To: Olivier Dion Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Nov 29 21:19:20 2022 Return-path: Envelope-to: guile-devel@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 1p074X-0009Vf-OB for guile-devel@m.gmane-mx.org; Tue, 29 Nov 2022 21:19:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p074N-0001u9-9f; Tue, 29 Nov 2022 15:19:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p073w-0001ps-9V for guile-devel@gnu.org; Tue, 29 Nov 2022 15:18:44 -0500 Original-Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p073t-0004FC-8p for guile-devel@gnu.org; Tue, 29 Nov 2022 15:18:39 -0500 Original-Received: by mail-ej1-x629.google.com with SMTP id ho10so36587910ejc.1 for ; Tue, 29 Nov 2022 12:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gvS5NLuz6PR8mGO9AaXlLJdoW/T4XLjZ0lJv2CvPrQw=; b=MUs6RQf6zu0NALU2ElTrOKkJZu0I77tzYZ45HELHuDG8ZUUWbn4KEWPs1xxijQf6ew RVXphQ6dZ+AHfQdsSXfU8a1iqmQBfhSXLG58ocF/PbFGDl8MzXZ2cAOjZo9PGdHiBso9 9pA4UVRu6IVyUVKLJB+mgwwjkTMR00OJqqSt9JbvtETj9FSIFDc9XCku0WiclFyMBPt7 cuTc+5Y3e603KrGWGYkWa+qS3pT+bHnWMf4cTKm8IXgZCn9IRPn4C8jti8jyiwZeTUSh sXPVnwlKxLRFSC58IwHCENRbqGPq4lqUDJrsoVSTqBf/Wnwscq07r3r/Cb3K9lUCR6Xl Rxcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gvS5NLuz6PR8mGO9AaXlLJdoW/T4XLjZ0lJv2CvPrQw=; b=PiiOk6knjrVi6sqmH5IKYoQToSwjIUO2I1KbgpuhEjU+gTFzyjfWbHCT8o5Xgw5REC viLLPxcIxq3T+FzT6JPnbnaqp2lO6fwTe82DYIVevyURxWULBtO/W0jBztqbT79MwgFg vjrSYVR6QQR2i/P5JkRM0dLLwsvvFFI1SlFe3MghREjma7iP0SqQ4OLiAQoFZJkCEDUS qQaAHG3hhI0KfHu/USadJAYMBSvxZ6VUuG9XnShRYzIquAJc7DSMLZEnS3QEefzrk+mD JeBX6LBJM1QsX/04N/ulH65S5HaMHufrT5Lw/wEGmawedlyFbRgMiQehK0FkU8cYSi6l g75A== X-Gm-Message-State: ANoB5plZB7nSQTwy4Wl4V33Pm9KWdTVZdxnhygXdnRXyTCfTLpyjahc4 To6jSHXW9xgZa1w6vGdkbwd5h3/Uv8/S/19d2BY= X-Google-Smtp-Source: AA0mqf5wOqewCeju0YC15OkUnpoOjLWfVPZkTQMY4fVcG57gDrC/mxhev9kUskdPXWoyWLwCldUq2yM82UG54c94bpU= X-Received: by 2002:a17:906:2810:b0:7b2:7b45:2bf6 with SMTP id r16-20020a170906281000b007b27b452bf6mr33451924ejc.467.1669753115181; Tue, 29 Nov 2022 12:18:35 -0800 (PST) In-Reply-To: <87edtlptgv.fsf@laura> Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=damien.mattei@gmail.com; helo=mail-ej1-x629.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21491 Archived-At: --0000000000004b097805eea1b19c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, i almost never use a debugger but in C as a student. Never after. programming in a functional style and if in need print some debug information, all my program worked and the only hard problem were not due to implementation but algorithm,and for that the debugger is useless... http://i-exc.ccm2.net/iex/1280/1809789201/893758.jpg but this is my personal opinion :-) Regards, Damien On Tue, Nov 29, 2022 at 6:21 PM Olivier Dion via Developers list for Guile, the GNU extensibility library wrote: > Greetings Guilers, > > There's been a discussion on the state of debugging with Guile on the > guix-devel mailing list. Here's the relevant link if you want the full > discussion: > > which is a reply to . > > I'm going to resume what I've gather here. I've mainly cutoff Guix > related stuff. I'm also putting names here for the sake of clarity. > > I think it would be interesting to have more inputs from the Guile users > at large -- outside of Guix -- on that topic. From my personal > experience and the echo I get back from other users, the debugging > experience in Guile is frustrating. > > Things I've gather in this reading and on the IRC with other users. > This is by no way a wish list, but simply ideas to improve the debugging > experience: > > 1. Documentation on debugging should be improved. e.g. The `pk` > procedure. > > 2. A tutorial on how to debug a project with `pk` and the REPL. > > 3. A single-step (instruction and line) debugger. > > 4. Integration in GDB. e.g. GDB could insert breakpoints in Scheme > code. > > 5. Maybe not make a debugger with a paradigm for language like C but > instead take inspiration from other Scheme implementation like > Racket. > > Resume start here: > > zimon: > > Preparing some materials for introducing Guile to GuixHPC folk, I am > trying to collect some tips and, if I am honest, the debugging > experience with Guile is really poor; compared to others (as Python). > For example, DrRacket provides an easy and nice user experience > > Well, IMHO, we are somehow suffering from some Guile limitations and > improvements in this area are an hard task. > > Maxim: > > I also agree! It's hard to convince people to pick Guile for their > project when there is: > > 1. Lack of a debugger that can break and step anywhere in your source > code > > 2. Lack of debugger integration to an IDE (it's not even integrated > into Emacs) > > Perhaps we should assemble a Guile debugger workgroup that'd review > what's broken, what's missing, what can be borrowed from other Scheme > or languages for inspiration > > Ludo: > > Well, Guile has a debugger that lets you do that [...] Geiser is not > Visual Studio=E2=84=A2 but it does a good job. > > Also, [...] I mentioned before that I almost never use breakpoints on > Guile code [...] because it=E2=80=99s rarely the right tool for the jo= b. > > I believe this is largely due to (1) writing functional code, and (2) > doing live programming at the REPL. Why would you use breakpoints > when you can just call the relevant procedures on some input to see > how they behave? > > So I think you won=E2=80=99t convince people to pick Guile for their pr= oject > by selling it as a C/C++/Python drop-in replacement. Guile is about > functional programming and live coding so the set of tools differs. > > Despite what I wrote, I think it=E2=80=99s a good idea. I suppose insp= iration > would come from other Schemes, in particular Racket, and perhaps from > other live-coding systems (Common Lisp, Smalltalk, etc.), rather than > from Python or C. > > Zimon: > > Maybe I am wrong or miss some Guile features. From my experience, the > issue is not the way that the information is presented or how we > interact with it (Geiser or else) but, instead, the issue is the > availability of such information. > > Well, so you are using the good ol=E2=80=99 way putting =E2=80=99pk=E2= =80=99 here or there, > right? One thing when debugging is to inspect the current state of > the program; [...] And, =E2=80=99pk=E2=80=99 is the poor man breakpoint= . :-) > > Racket is an example of functional programming and live coding. > Haskell is another; it is functional programming and if I might, I > would recommend to give a look at the interactive GHCi debugger > > Maxim: > > When searching for how the debugger work in the Guile Reference info > manual, I also don't find anything useful: only the gut of the > debugging API of the Guile VM appears to be documented ("Debugging > Infrastructure"), so documentation is another place that could be > improved, with some examples and pro tips for real life, practical > debugging with Guile. > > Ludo: > > I think we should identify scenarios where things don=E2=80=99t work as > expected, and then turn them into bug reports, documentation issues, > or any other concrete action we should take. > > [...] that brings us back to Maxim=E2=80=99s suggestion of starting a > debugger workgroup. > > Attila: > > [C]oming from common lisp [...], [I] think the lowest hanging fruit in > the guile debugging experience is making sure that backtraces are not > cut short when printed. > > [T]his is regularly causing me frustration when all i need to make > progress is in the cut off part of the backtrace, and the code in > question is in a part of the codebase that i can't easily change to > add some good old printf's. > > Joshua: > > Just my 2 cents, I always thought that the elisp debugging experince > is super user friendly and awesome! > > M-x edebug-defun RET function-name RET > > And you are golden! > > It would be awesome if guile could offer something as seemless. > > Csepp: > > Can we also get a profiler like Python's Scalene? I'm pretty sure > there are some performance bottlenecks it could help identify, both in > Guix and in Guile itself. > > -- > Olivier Dion > oldiob.dev > > > --0000000000004b097805eea1b19c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hel= lo,

i almost never us= e a debugger but in C as a student.
Never after.
programming in a functional style and if in need pri= nt some debug information, all my program worked and the only hard problem = were not due to implementation but algorithm,and for that the debugger is u= seless...

<= /div>
http://i-exc.ccm2.net/iex= /1280/1809789201/893758.jpg

but this is my personal opinion :-)

Regards,
Damien


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 29, 2022 at 6:21 PM Olivie= r Dion via Developers list for Guile, the GNU extensibility library <guile-devel@gnu.org> wrote:
<= /div>
Greetings Guilers,
There's been a discussion on the state of debugging with Guile on the guix-devel mailing list.=C2=A0 Here's the relevant link if you want the= full
discussion:
<https://lists.gnu.org/archive= /html/guix-devel/2022-11/msg00283.html>
which is a reply to <https://issues.guix.gnu.org/i= ssue/58812#id=3D33>.

I'm going to resume what I've gather here.=C2=A0 I've mainly cu= toff Guix
related stuff.=C2=A0 I'm also putting names here for the sake of clarit= y.

I think it would be interesting to have more inputs from the Guile users at large -- outside of Guix -- on that topic.=C2=A0 From my personal
experience and the echo I get back from other users, the debugging
experience in Guile is frustrating.

Things I've gather in this reading and on the IRC with other users.
This is by no way a wish list, but simply ideas to improve the debugging experience:

=C2=A0 1. Documentation on debugging should be improved.=C2=A0 e.g. The `pk= `
=C2=A0 =C2=A0 =C2=A0procedure.

=C2=A0 2. A tutorial on how to debug a project with `pk` and the REPL.

=C2=A0 3. A single-step (instruction and line) debugger.

=C2=A0 4. Integration in GDB.=C2=A0 e.g. GDB could insert breakpoints in Sc= heme
=C2=A0 =C2=A0 =C2=A0code.

=C2=A0 5. Maybe not make a debugger with a paradigm for language like C but=
=C2=A0 =C2=A0 =C2=A0instead take inspiration from other Scheme implementati= on like
=C2=A0 =C2=A0 =C2=A0Racket.

Resume start here:

zimon:

=C2=A0 Preparing some materials for introducing Guile to GuixHPC folk, I am=
=C2=A0 trying to collect some tips and, if I am honest, the debugging
=C2=A0 experience with Guile is really poor; compared to others (as Python)= .
=C2=A0 For example, DrRacket provides an easy and nice user experience

=C2=A0 Well, IMHO, we are somehow suffering from some Guile limitations and=
=C2=A0 improvements in this area are an hard task.

Maxim:

=C2=A0 I also agree!=C2=A0 It's hard to convince people to pick Guile f= or their
=C2=A0 project when there is:

=C2=A0 1. Lack of a debugger that can break and step anywhere in your sourc= e
=C2=A0 =C2=A0 =C2=A0code

=C2=A0 2. Lack of debugger integration to an IDE (it's not even integra= ted
=C2=A0 =C2=A0 =C2=A0into Emacs)

=C2=A0 Perhaps we should assemble a Guile debugger workgroup that'd rev= iew
=C2=A0 what's broken, what's missing, what can be borrowed from oth= er Scheme
=C2=A0 or languages for inspiration

Ludo:

=C2=A0 Well, Guile has a debugger that lets you do that [...] Geiser is not=
=C2=A0 Visual Studio=E2=84=A2 but it does a good job.

=C2=A0 Also, [...] I mentioned before that I almost never use breakpoints o= n
=C2=A0 Guile code [...]=C2=A0 because it=E2=80=99s rarely the right tool fo= r the job.

=C2=A0 I believe this is largely due to (1) writing functional code, and (2= )
=C2=A0 doing live programming at the REPL.=C2=A0 Why would you use breakpoi= nts
=C2=A0 when you can just call the relevant procedures on some input to see<= br> =C2=A0 how they behave?

=C2=A0 So I think you won=E2=80=99t convince people to pick Guile for their= project
=C2=A0 by selling it as a C/C++/Python drop-in replacement.=C2=A0 Guile is = about
=C2=A0 functional programming and live coding so the set of tools differs.<= br>
=C2=A0 Despite what I wrote, I think it=E2=80=99s a good idea.=C2=A0 I supp= ose inspiration
=C2=A0 would come from other Schemes, in particular Racket, and perhaps fro= m
=C2=A0 other live-coding systems (Common Lisp, Smalltalk, etc.), rather tha= n
=C2=A0 from Python or C.

Zimon:

=C2=A0 Maybe I am wrong or miss some Guile features.=C2=A0 From my experien= ce, the
=C2=A0 issue is not the way that the information is presented or how we
=C2=A0 interact with it (Geiser or else) but, instead, the issue is the
=C2=A0 availability of such information.

=C2=A0 Well, so you are using the good ol=E2=80=99 way putting =E2=80=99pk= =E2=80=99 here or there,
=C2=A0 right?=C2=A0 One thing when debugging is to inspect the current stat= e of
=C2=A0 the program; [...] And, =E2=80=99pk=E2=80=99 is the poor man breakpo= int. :-)

=C2=A0 Racket is an example of functional programming and live coding.
=C2=A0 Haskell is another; it is functional programming and if I might, I =C2=A0 would recommend to give a look at the interactive GHCi debugger

Maxim:

=C2=A0 When searching for how the debugger work in the Guile Reference info=
=C2=A0 manual, I also don't find anything useful: only the gut of the =C2=A0 debugging API of the Guile VM appears to be documented ("Debugg= ing
=C2=A0 Infrastructure"), so documentation is another place that could = be
=C2=A0 improved, with some examples and pro tips for real life, practical =C2=A0 debugging with Guile.

Ludo:

=C2=A0 I think we should identify scenarios where things don=E2=80=99t work= as
=C2=A0 expected, and then turn them into bug reports, documentation issues,=
=C2=A0 or any other concrete action we should take.

=C2=A0 [...] that brings us back to Maxim=E2=80=99s suggestion of starting = a
=C2=A0 debugger workgroup.

Attila:

=C2=A0 [C]oming from common lisp [...], [I] think the lowest hanging fruit = in
=C2=A0 the guile debugging experience is making sure that backtraces are no= t
=C2=A0 cut short when printed.

=C2=A0 [T]his is regularly causing me frustration when all i need to make =C2=A0 progress is in the cut off part of the backtrace, and the code in =C2=A0 question is in a part of the codebase that i can't easily change= to
=C2=A0 add some good old printf's.

Joshua:

=C2=A0 Just my 2 cents, I always thought that the elisp debugging experince=
=C2=A0 is super user friendly and awesome!

=C2=A0 M-x edebug-defun RET function-name RET

=C2=A0 And you are golden!

=C2=A0 It would be awesome if guile could offer something as seemless.

Csepp:

=C2=A0 Can we also get a profiler like Python's Scalene?=C2=A0 I'm = pretty sure
=C2=A0 there are some performance bottlenecks it could help identify, both = in
=C2=A0 Guix and in Guile itself.

--
Olivier Dion
oldiob.d= ev


--0000000000004b097805eea1b19c--