Re: Guile debugger workgroup?

[Jannneke Nieuwenhuizen]

Maxim Cournoyer writes:

> Hi Simon,
>
> zimoun  writes:
>
>> Hi Maxim,
>>
>> On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer  
>> wrote:

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

> I also agree!  It's hard to convince people to pick Guile for their
> project when there is:

Yes, I thought so too.  I made an attempt to do these thingssome time
ago, but did not fully see it through.

> 1. Lack of a debugger that can break and step anywhere in your source
> code

I didn't get thse patches to work

https://lists.gnu.org/archive/html/guile-devel/2014-08/msg4.html

> 2. Lack of debugger integration to an IDE (it's not even integrated into
> Emacs)

This made it into Emacs, though

https://lists.gnu.org/archive/html/guile-devel/2014-08/msg6.html

Greetinsgs,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: Guile debugger workgroup?

[Attila Lendvai]

> > > The scenario you describe above should be possible above (there is a
> > > debugger that supports breakpoints and single stepping). Now, it may
> > > be, as you wrote, that inlining can lead breakpoints to never be hit, or
> > > that there are bugs in this area. These things should be fixed, I agree.
> > 
> > i'm sure there's a way to globally override the debug/optimization/inlining 
> > level in guile to make sure the code compiles in a way that no breakpoints 
> > are missed (and/or backtraces remain more intact, etc).
> 
> 
> Note that I’m not even sure this bug exists (hence “may” :-)) but if it
> does, you’re right, it’s probably a matter of compiling with -O1.


i would be quite surprised if brakepoints in Guile worked on inlined function 
invocations... but hey! i like positive surprises! :)

but in general, optimized code is usually less debuggable due to the tradeoffs 
taken. having a means to force parts of the codebase to run in unoptimized form 
is usually very helpful when debugging.

and sometimes it makes sense to straight out force parts of the code to always 
be unoptimized, or run in the interpreter, if it's not in a hotspot of the 
codebase, and it's expected to be involved often in situations where errors are 
raised.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Liberty means responsibility. That is why most men dread it.”
— George Bernard Shaw (1856–1950), 'Man and Superman'

Re: Guile debugger workgroup?

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

> the first thing that pops to my mind is the service start gexp's in shepherd: 
> they felt impossible to debug. i often was pretty much resorting to staring 
> at the code, and then trying ad-hoc changes (with a minute+ long 
> edit-compile-test cycle).

Ah yes.  That’s a problem that has to do with staging, which makes
things more difficult.

The one multi-stage language I know of that did it well, but in a
totally different context, is Hop .
 briefly discusses
cross-stage debugging.

> there are multiple issues here. the first one is that there's no proper error 
> handling in shepherd. but if there was at least a semi-global error handler, 
> that logged a full backtrace into a log file, then it would have been 
> immensely helpful.

OK.  I guess there are cases where you do get logging with Shepherd 0.9,
and other cases less so (e.g., if the ‘start’ method refers to an
unbound variable).  We should look at typical examples to get a better
understanding of what’s missing.

> for inspiration, this is what we developed in common lisp:
>
> https://hub.darcs.net/hu.dwim/hu.dwim.util/browse/source/error-handling.lisp#10
>
> WITH-LAYERED-ERROR-HANDLERS is a macro for which you can provide a "level 1" 
> error handler hook that does whatever it wants. if any errors happen within 
> this hook, then a level2 error handler kicks in, turns off several things 
> (e.g. custom PRINT-OBJECT methods), and tries to log a backtrace in a 
> defensive way (e.g. there are error handlers installed while printing each 
> backtrace level).
>
> if even level2 errors out, then a super conservative level3 error handler 
> logs this fact, so that there's *some* sign of an error.

Looks like a good source of inspiration!

Thanks,
Ludo’.

Re: Guile debugger workgroup?

[Ludovic Courtès]

Attila Lendvai  skribis:

>> The scenario you describe above should be possible above (there is a
>> debugger that supports breakpoints and single stepping). Now, it may
>> be, as you wrote, that inlining can lead breakpoints to never be hit, or
>> that there are bugs in this area. These things should be fixed, I agree.
>
>
> i'm sure there's a way to globally override the debug/optimization/inlining 
> level in guile to make sure the code compiles in a way that no breakpoints 
> are missed (and/or backtraces remain more intact, etc).

Note that I’m not even sure this bug exists (hence “may” :-)) but if it
does, you’re right, it’s probably a matter of compiling with -O1.

Ludo’.

Re: Guile debugger workgroup?

[Maxim Cournoyer]

Hi,

Attila Lendvai  writes:

>> The scenario you describe above should be possible above (there is a
>> debugger that supports breakpoints and single stepping). Now, it may
>> be, as you wrote, that inlining can lead breakpoints to never be hit, or
>> that there are bugs in this area. These things should be fixed, I agree.
>
>
> i'm sure there's a way to globally override the
> debug/optimization/inlining level in guile to make sure the code
> compiles in a way that no breakpoints are missed (and/or backtraces
> remain more intact, etc).

The Guile documentation itself doesn't seem to be covered for that.
It'd be a good place to start in my opinion.

> this should also be added to the documentation, especially in the guix
> context, where it's very much not as trivial as to change a command
> line argument to e.g. start the guix daemon, or shepherd, in a
> configuration that makes things more debuggable.

That'd be nice yes.  I think we should add the nice ideas/things noted
here in a "Improve debbuging experience" section of the
maintenance/doc/ROADMAP.org TODO.

I'll get to it if no-one beats me to it.

-- 
Thanks,
Maxim

Re: Guile debugger workgroup?

[Attila Lendvai]

> Do you have examples in mind of things you’d like to log and that would
> have helped you on a debugging journey?


the first thing that pops to my mind is the service start gexp's in shepherd: 
they felt impossible to debug. i often was pretty much resorting to staring at 
the code, and then trying ad-hoc changes (with a minute+ long edit-compile-test 
cycle).

there are multiple issues here. the first one is that there's no proper error 
handling in shepherd. but if there was at least a semi-global error handler, 
that logged a full backtrace into a log file, then it would have been immensely 
helpful.

for inspiration, this is what we developed in common lisp:

https://hub.darcs.net/hu.dwim/hu.dwim.util/browse/source/error-handling.lisp#10

WITH-LAYERED-ERROR-HANDLERS is a macro for which you can provide a "level 1" 
error handler hook that does whatever it wants. if any errors happen within 
this hook, then a level2 error handler kicks in, turns off several things (e.g. 
custom PRINT-OBJECT methods), and tries to log a backtrace in a defensive way 
(e.g. there are error handlers installed while printing each backtrace level).

if even level2 errors out, then a super conservative level3 error handler logs 
this fact, so that there's *some* sign of an error.

note that the logging library must also be smart about how it deals with errors.

the default level1 handler has fancy features like "backtrace decorators", 
which is a registry of dinamically bound thunks that are called when a 
backtrace is printed. they can decorate the end of the backtrace with dynamic 
information from the context that is not captured by the backtrace (e.g. the 
web session, the user logged in, etc).

this error handler mechanism is installed at strategic points, like the 
handling of a http request, or a great candidate would be when calling the user 
code in the start gexp of a shpeherd service.

let me know if anything like this is available in scheme.

i know about these in guix and guile:

/guix/ui.scm: (define (call-with-error-handling

/module/system/repl/error-handling.scm: (define* (call-with-error-handling

the longer i work on/in guix, the higher the chance that i'll port parts of our 
CL debugging stuff to scheme. i think i was just procractinating it until i 
develop a deep enough understanding of scheme to do it properly.

HTH,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“We are caged by our cultural programming. Culture is a mass hallucination, and 
when you step outside the mass hallucination you see it for what it's worth.”
— Terence McKenna (1946–2000), from the lecture 'Eros and the Eschaton' 
(1994)

Re: Guile debugger workgroup?

[Attila Lendvai]

> The scenario you describe above should be possible above (there is a
> debugger that supports breakpoints and single stepping). Now, it may
> be, as you wrote, that inlining can lead breakpoints to never be hit, or
> that there are bugs in this area. These things should be fixed, I agree.


i'm sure there's a way to globally override the debug/optimization/inlining 
level in guile to make sure the code compiles in a way that no breakpoints are 
missed (and/or backtraces remain more intact, etc).

this should also be added to the documentation, especially in the guix context, 
where it's very much not as trivial as to change a command line argument to 
e.g. start the guix daemon, or shepherd, in a configuration that makes things 
more debuggable.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Knowledge makes a man unfit to be a slave.”
— Frederick Douglass (1818–1895), a former slave.

Re: Guile debugger workgroup?

[zimoun]

Hi,

On Mon, 28 Nov 2022 at 12:06, Ludovic Courtès  wrote:

> Why doesn’t it work in ‘guix repl’?  Because auto-compilation is
> disabled:

Ah, thanks.  Well, maybe we could have an option to start “guix repl”
with debug mode available… even if it is really slow.


> I think we should identify scenarios where things don’t work as
> expected, and then turn them into bug reports, documentation issues, or
> any other concrete action we should take.

The example I provided is, IMHO, a good scenario for starting. :-)  For
instance, ,step by ,step works,

--8<---cut here---start->8---
$ guix shell guile -- guile -q
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (load "/tmp/my-target.scm")
scheme@(guile-user)> ,break example
Trap 0: Breakpoint at #.
scheme@(guile-user)> (example #t)
Trap 0: Breakpoint at #
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
 17:0  0 (example #t)
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
19:21  0 (example _)
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
19:20  1 (example _)
  3:0  0 (mutate-once "something")
scheme@(guile-user) [1]> 
--8<---cut here---end--->8---

but then I do not know how many steps are required to reach the other
’mutate-twice’.

--8<---cut here---start->8---
Step into #
Step into #
4x Step into #
5x Step into #
4x Step into #
Step into #
10x Step into #
4x Step into #
Step into #
6x Step into #
3x Step into #
5x Step into #
Step into #
…
--8<---cut here---end--->8---

And I do not know if ,break-at-source works correctly.

--8<---cut here---start->8---
$ cat -n /tmp/my-target.scm | grep 20
20   (my-target (mutate-twice my-target)))

$ guix shell guile -- guile -q
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (load "/tmp/my-target.scm")
scheme@(guile-user)> ,break example
Trap 0: Breakpoint at #.
scheme@(guile-user)> (example #t)
Trap 0: Breakpoint at #
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
 17:0  0 (example #t)
scheme@(guile-user) [1]> ,break-at-source "/tmp/my-target.scm" 20
Trap 1: Breakpoint at /tmp/my-target.scm:20.
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
 17:0  0 (example #t)
scheme@(guile-user) [1]> ,next
Step into #
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
19:21  0 (example _)
scheme@(guile-user) [1]> ,locals
  No local variables.
scheme@(guile-user) [1]>
--8<---cut here---end--->8---


Cheers,
simon

Re: Guile debugger workgroup? (was: Coding style: similarly-named variables)

[Csepp]

Maxim Cournoyer  writes:

> Hi Simon,
>
> zimoun  writes:
>
>> Hi Maxim,
>>
>> On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer  
>> wrote:
>>
>>> In practice since using breakpoints/a debugger to debug Guile code
>>> rarely works as intended (in my experience hacking on Guix!), we
>>> typically sprinkle the source with 'pk', and that point becomes moot.
>>
>> I totally agree!  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 [1] – where it is easy to compare each intermediary result in
>> the debugger.  For what it is worth, I have not been able to have some
>> similar inspections as in [1].  Maybe, I am missing something…
>>
>> Well, IMHO, we are somehow suffering from some Guile limitations and
>> improvements in this area are an hard task.
>
> 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, and hopefully improve the Guile debugging
> experience? :-)

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.

Re: Guile debugger workgroup?

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

> which reminds me that a project-wide logging infrastructure would also 
> greatly elevate the guix debugging experience.

Do you have examples in mind of things you’d like to log and that would
have helped you on a debugging journey?

Ludo’.

Re: Guile debugger workgroup?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> scheme@(guix-user)> ,break example
> Trap 2: Breakpoint at #.
> scheme@(guix-user)> (example #t)
> $2 = 20

I get this:

--8<---cut here---start->8---
$ guile
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (load "/tmp/example.scm")
;;; note: source file /tmp/example.scm
;;;   newer than compiled 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.6/tmp/example.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /tmp/example.scm
;;; : warning: possibly unused local top-level variable 
`mutate-once'
;;; : warning: possibly unused local top-level variable 
`mutate-twice'
;;; : warning: possibly unused local top-level variable 
`do-something-with'
;;; : warning: possibly unused local top-level variable 
`example'
;;; compiled /home/ludo/.cache/guile/ccache/3.0-LE-8-4.6/tmp/example.scm.go
scheme@(guile-user)> ,break example
Trap 0: Breakpoint at #.
scheme@(guile-user)> (example #t)
Trap 0: Breakpoint at #
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
In /tmp/example.scm:
 17:0  0 (example #t)
scheme@(guile-user) [1]> ,locals
  No local variables.
--8<---cut here---end--->8---

and then:

--8<---cut here---start->8---
scheme@(guile-user) [1]> ,q
$1 = 20
scheme@(guile-user)> ,break /tmp/example.scm 17
While executing meta-command:
Wrong number of arguments to #
scheme@(guile-user)> ,break-at /tmp/example.scm 17
Trap 1: Breakpoint at /tmp/example.scm:17.
scheme@(guile-user)> (example #t)
Trap 1: Breakpoint at /tmp/example.scm:17
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,q
Trap 0: Breakpoint at #
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
--8<---cut here---end--->8---

Why doesn’t it work in ‘guix repl’?  Because auto-compilation is
disabled:

--8<---cut here---start->8---
$ head -1 $(type -P guix)
#!/gnu/store/805g934pgy3955g87ld6qixny6biwmj3-guile-wrapper/bin/guile 
--no-auto-compile
--8<---cut here---end--->8---

… which in turn causes ‘load’ to evaluate code.

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

And I guess that brings us back to Maxim’s suggestion of starting a
debugger workgroup.  :-)

Ludo’.

Re: Guile debugger workgroup?

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> Also, I think I mentioned before that I almost never use breakpoints on
>> Guile code—not because of some deficiency of the debugger, not (just)
>> because I’m silly or inexperienced, but because it’s rarely the right
>> tool for the job.
>>
>> 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?
>
> And I've probably countered that before by saying that while it's true
> that functional programming helps, there are still times where the
> inputs or the lexical environment I need to understand are complex
> enough that reproducing them at the global level (REPL) is a pain.  Just
> breaking at the right place and typing ,locals would be a much more
> efficient way to proceed to see what the environment in scope looks
> like.

Agreed, I didn’t mean to suggest that breakpoints are never useful.

The scenario you describe above should be possible above (there *is* a
debugger that supports breakpoints and single stepping).  Now, it may
be, as you wrote, that inlining can lead breakpoints to never be hit, or
that there are bugs in this area.  These things should be fixed, I agree.

Ludo’.

Re: Guile debugger workgroup?

[Joshua Branson]

Maxim Cournoyer  writes:

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.  :)

Re: Guile debugger workgroup?

[Maxim Cournoyer]

Hi Attila,

Attila Lendvai  writes:

> coming from common lisp (and SBCL in particular), i think the lowest
> hanging fruit in the guile debugging experience is making sure that
> backtraces are not cut short when printed.
>
> i tried multiple ways to configure the printer to acquire more info,
> but it didn't react to anything i tried:
>
> (setenv "COLUMNS" "300")
> (debug-set! width 160)
> (debug-set! depth 1000)
>
> this 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.

Thanks for reminding me of this problem.  I thought the following might
do it:

--8<---cut here---start->8---
modified   doc/guix.texi
@@ -18263,6 +18263,10 @@ This data type represents the configuration of the 
Guix build daemon.
 @item @code{guix} (default: @var{guix})
 The Guix package to use.
 
+@item @code{backtrace-width} (default: @var{400})
+The character width at which backtraces of Guile processes launched by
+the Guix daemon should be truncated.
+
 @item @code{build-group} (default: @code{"guixbuild"})
 Name of the group for build user accounts.
 
modified   gnu/services/base.scm
@@ -187,6 +187,7 @@ (define-module (gnu services base)
 guix-configuration?
 
 guix-configuration-guix
+guix-configuration-backtrace-width
 guix-configuration-build-group
 guix-configuration-build-accounts
 guix-configuration-authorize-key?
@@ -1634,6 +1635,8 @@ (define-record-type* 
 (default 0))
   (timeout  guix-configuration-timeout;integer
 (default 0))
+  (backtrace-width  guix-configuration-backtrace-width ;integer
+(default 400))
   (log-compression  guix-configuration-log-compression
 (default 'gzip))
   (discover?guix-configuration-discover?
@@ -1701,7 +1704,7 @@ (define (guix-shepherd-service config)
 (guix build-group build-accounts authorize-key? authorized-keys
   use-substitutes? substitute-urls max-silent-time timeout
   log-compression discover? extra-options log-file
-  http-proxy tmpdir chroot-directories)
+  http-proxy tmpdir chroot-directories backtrace-width)
 (list (shepherd-service
(documentation "Run the Guix daemon.")
(provision '(guix-daemon))
@@ -1771,6 +1774,9 @@ (define discover?
 (list (string-append "TMPDIR=" tmpdir))
 '())
 
+ #$(string-append "COLUMNS=" (number->string
+  backtrace-width))
+
  ;; Make sure we run in a UTF-8 locale so that
  ;; 'guix offload' correctly restores nars
  ;; that contain UTF-8 file names such as
--8<---cut here---end--->8---

But it doesn't seem to work :-(.

> which reminds me that a project-wide logging infrastructure would also
> greatly elevate the guix debugging experience.

I wouldn't be against having a logging system in Guix; there's a readily
available logging library part of guile-lib; see info '(guile-library)
loggig logger')

-- 
Thanks,
Maxim

Re: Guile debugger workgroup?

[David Pirotte]

> there are just 'scared' to implement it ...

*they are just scared ... 


pgpKcbuSKCylj.pgp
Description: OpenPGP digital signature

Re: Guile debugger workgroup?

[David Pirotte]

Hello Attila,

> coming from common lisp (and SBCL in particular), i think the lowest
> hanging fruit in the guile debugging experience is making sure that
> backtraces are not cut short when printed.

Not 'by default' though, I would personally vote against such a change
[1].

Did you try, after the exception is raised:

,bt #:full? #t :#width 1000 (or higher if needed)

That always worked for me.

David

[1]

Fwiw, I am actually trying to get our maintainers to accept to set the
very same 'truncate' defaults for both repl printiers [2] and raised
exception printers [3].

[2]

repl printers can be easily configured by users though, even for none
experimented users, so ok but I would still prefer the default to
truncate the output. Here is how though, for those interested


https://www.gnu.org/software/guile-cv/manual/html_node/Configuring-Guile_0027s-repl_002dprint-procedure.html

[3]

raised exception printer are next to impossible to configure for none
experimented users, and even 'advanced' or 'very advanced' guilers 
do not know how to do this, and when advised with the proper solution,
there are just 'scared' to implement it (which I understand, as the
solution requires to patch (ice-9 boot-9).

This is explained here, again, fwiw:


https://www.gnu.org/software/guile-cv/manual/html_node/Configuring-Guile_0027s-raised-exception-system.html

But there is a patch, if you prefer

https://git.savannah.gnu.org/cgit/guile.git?h=wip-exception-truncate

https://git.savannah.gnu.org/cgit/guile.git/commit/?h=wip-exception-truncate=1a919d98514f1184b91085a19b55a4c719300149

[ for guile-3.0 ofc, and you'd need to install from the source
[ in the first place, then cherry pick the patch ...




pgpTIO5w19klx.pgp
Description: OpenPGP digital signature

Re: Guile debugger workgroup?

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

[...]

> 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 [1].
>
> Back to the initial example [2].  Racket is able to set breakpoints at
> various places, as shown in the short demo [3].  Well, I am not able to
> do that with Guile.
>
> $ cat -n my-target.scm
>  1;#lang racket
>  2
>  3(define (mutate-once x)
>  4  (let ((once "once")
>  5(dash "-"))
>  6(string-append x dash once)))
>  7
>  8(define (mutate-twice x)
>  9  (let* ((dash "-")
> 10 (twice "twice")
> 11 (stuff (string-append twice dash)))
> 12  (string-append "twice-" x)))
> 13
> 14(define (do-something-with x)
> 15  (string-length x))
> 16
> 17(define (example x)
> 18  (let* ((my-target "something")
> 19 (my-target (mutate-once my-target))
> 20 (my-target (mutate-twice my-target)))
> 21(do-something-with my-target)))
>
>
> then,
>
> $ guix repl
> GNU Guile 3.0.8
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guix-user)> (load "my-target.scm")
> scheme@(guix-user)> ,break-at-source "my-target.scm" 17
> While executing meta-command:
> No procedures found at ~a:~a. "my-target.scm" 17
> scheme@(guix-user)> ,break-at-source "/home/simon/tmp/my-target.scm" 17
> While executing meta-command:
> No procedures found at ~a:~a. "/home/simon/tmp/my-target.scm" 17
> scheme@(guix-user)> (example #t)
> $1 = 20
> scheme@(guix-user)> ,break example
> Trap 2: Breakpoint at #.
> scheme@(guix-user)> (example #t)
> $2 = 20
> scheme@(guix-user)>
>
>
> How can I enter in the debugger?  Do I only enter on error?  Well, I end
> to put ’pk’ here and there to inspect the code.  Poor experience. :-)
>
> Just to compare with Haskell (functional style, where it is hard nor
> impossible to put equivalent of ’pk’ here or there :-)) – the code is
> the equivalent as above.
>
>  1mutate_once x = x ++ dash ++ once
>  2  where
>  3once = "once"
>  4dash = "-"
>  5
>  6mutate_twice x = stuff ++ x
>  7  where
>  8dash = "-"
>  9twice = "once"
> 10stuff = twice ++ dash
> 11
> 12do_something_with x = length x
> 13
> 14example x = do_something_with my_target
> 15  where
> 16my_target = mutate_twice my_target
> 17  where
> 18my_target = mutate_once my_target
> 19  where
> 20my_target = "something"
>
>
> then,
>
> $ guix shell ghc gcc-toolchain -- ghci
> GHCi, version 8.10.7: https://www.haskell.org/ghc/  :? for help
> Prelude> :load my-target.hs
> [1 of 1] Compiling Main ( my-target.hs, interpreted )
> Ok, one module loaded.
> *Main> :break 14
> Breakpoint 0 activated at my-target.hs:14:13-39
> *Main> example True
> Stopped in Main.example, my-target.hs:14:13-39
> _result :: Int = _
> my_target :: [Char] = _
> [my-target.hs:14:13-39] *Main> :list
> 13  
> 14  example x = do_something_with my_target
> ^^^
> 15where
> [my-target.hs:14:13-39] *Main> :break 18
> Breakpoint 1 activated at my-target.hs:18:21-41
> [my-target.hs:14:13-39] *Main> :continue
> Stopped in Main.example.my_target.my_target, my-target.hs:18:21-41
> _result :: [Char] = _
> my_target :: [Char] = _
> [my-target.hs:18:21-41] *Main> :list
> 17where
> 18  my_target = mutate_once my_target
> ^
> 19where
> [my-target.hs:18:21-41] *Main> my_target
> "something"
> [my-target.hs:18:21-41] *Main>
>
>
> Well, again maybe I miss how to use the Guile debugger.  From my small
> experience, I have hard time to debug and inspect Guile code.

I think your above example summarizes well what appears to be wrong with
the Guile debugging experience; at least I personally strongly relate.

We should turn this kind of scenario into unit tests for Guile; the
output of the workgroup could then be to make these pass!  There are
also paper cuts such as the malformed error message "No procedures found
at ~a:~a. "my-target.scm" 17".

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 

Re: Guile debugger workgroup?

[Attila Lendvai]

coming from common lisp (and SBCL in particular), i think the lowest hanging 
fruit in the guile debugging experience is making sure that backtraces are not 
cut short when printed.

i tried multiple ways to configure the printer to acquire more info, but it 
didn't react to anything i tried:

(setenv "COLUMNS" "300")
(debug-set! width 160)
(debug-set! depth 1000)

this 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.

which reminds me that a project-wide logging infrastructure would also greatly 
elevate the guix debugging experience.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
If you never heal from what hurt you, you'll bleed on people who didn't cut you.

Re: Guile debugger workgroup?

[zimoun]

Hi Ludo,

On Sat, 26 Nov 2022 at 12:22, Ludovic Courtès  wrote:

> Well, Guile has a debugger that lets you do that (modulo inlining etc.,
> as with any other compiler), and Geiser is not Visual Studio™ but it
> does a good job.

And you wrote elsewhere in the thread:

It may be more of a limitation of Geiser than of Guile.  I find
it more useful in “typical” imperative ELisp code than in
functional Scheme code, but it’d be nice to have either way!



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.  And that is one limitation of Guile,
IMHO.

> Also, I think I mentioned before that I almost never use breakpoints on
> Guile code—not because of some deficiency of the debugger, not (just)
> because I’m silly or inexperienced, but because it’s rarely the right
> tool for the job.

That’s interesting. :-) Well, so you are using the good ol’ way putting
’pk’ here or there, right?  One thing when debugging is to inspect the
current state of the program; what are the values of this or that, then
after running this other, etc.  And, ’pk’ is the poor man
breakpoint. :-)


> 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?

Well, I do not think you are not using breakpoint with Guile because the
code is functional style.  My guess is more that you have built your way
around the limitations of the Guile debugger.

For what this example is worth, I know people with 30+ years of
experience programming highly optimized C code and they never used GDB
or Valgrind or strace or else for debugging.  Doing all debugging with
plain ’printf’.  Well, because when they started, GDB and friends were
less efficient, other folk around were not used to these tools, etc.
And so they took habits without.


> So I think you won’t convince people to pick Guile for their project 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.

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 [1].

Back to the initial example [2].  Racket is able to set breakpoints at
various places, as shown in the short demo [3].  Well, I am not able to
do that with Guile.

--8<---cut here---start->8---
$ cat -n my-target.scm
 1  ;#lang racket
 2  
 3  (define (mutate-once x)
 4(let ((once "once")
 5  (dash "-"))
 6  (string-append x dash once)))
 7  
 8  (define (mutate-twice x)
 9(let* ((dash "-")
10   (twice "twice")
11   (stuff (string-append twice dash)))
12(string-append "twice-" x)))
13  
14  (define (do-something-with x)
15(string-length x))
16  
17  (define (example x)
18(let* ((my-target "something")
19   (my-target (mutate-once my-target))
20   (my-target (mutate-twice my-target)))
21  (do-something-with my-target)))
--8<---cut here---end--->8---

then,

--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> (load "my-target.scm")
scheme@(guix-user)> ,break-at-source "my-target.scm" 17
While executing meta-command:
No procedures found at ~a:~a. "my-target.scm" 17
scheme@(guix-user)> ,break-at-source "/home/simon/tmp/my-target.scm" 17
While executing meta-command:
No procedures found at ~a:~a. "/home/simon/tmp/my-target.scm" 17
scheme@(guix-user)> (example #t)
$1 = 20
scheme@(guix-user)> ,break example
Trap 2: Breakpoint at #.
scheme@(guix-user)> (example #t)
$2 = 20
scheme@(guix-user)>
--8<---cut here---end--->8---

How can I enter in the debugger?  Do I only enter on error?  Well, I end
to put ’pk’ here and there to inspect the code.  Poor experience. :-)

Just to compare with Haskell (functional style, where it is hard nor
impossible to put equivalent of ’pk’ here or there :-)) – the code is
the equivalent as above.

--8<---cut here---start->8---
 1  mutate_once x = x ++ dash ++ once
 2where
 3  once = "once"
 4  dash = "-"
 5  
 6  

Re: Guile debugger workgroup?

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> 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)
>
> Well, Guile has a debugger that lets you do that (modulo inlining etc.,
> as with any other compiler), and Geiser is not Visual Studio™ but it
> does a good job.

I'll try to get more concrete with actual scenarios, but for now it's
just a feeling that "it rarely works", e.g. break points don't stop or
the code stepped is hardly recognizable.  Perhaps Guile aggressively
inline things or macros add to the confusion, but that shouldn't be a
price the user has to pay for.  One of Guile's strong points is supposed
to be that it's geared for interactive programming, and I'd categorize
stepping code being related to the programming experience being
"interactive".

> Also, I think I mentioned before that I almost never use breakpoints on
> Guile code—not because of some deficiency of the debugger, not (just)
> because I’m silly or inexperienced, but because it’s rarely the right
> tool for the job.
>
> 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?

And I've probably countered that before by saying that while it's true
that functional programming helps, there are still times where the
inputs or the lexical environment I need to understand are complex
enough that reproducing them at the global level (REPL) is a pain.  Just
breaking at the right place and typing ,locals would be a much more
efficient way to proceed to see what the environment in scope looks
like.

> So I think you won’t convince people to pick Guile for their project 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.

Debugging/live coding abilities do not have to be mutually exclusive.
Python excels at both, in my experience.

>> 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, and hopefully improve the Guile debugging
>> experience? :-)
>
> Despite what I wrote, I think it’s a good idea.  I suppose inspiration
> 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.

Great!

-- 
Thanks,
Maxim

Re: Guile debugger workgroup?

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> 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)

Well, Guile has a debugger that lets you do that (modulo inlining etc.,
as with any other compiler), and Geiser is not Visual Studio™ but it
does a good job.

Also, I think I mentioned before that I almost never use breakpoints on
Guile code—not because of some deficiency of the debugger, not (just)
because I’m silly or inexperienced, but because it’s rarely the right
tool for the job.

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’t convince people to pick Guile for their project 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.

> 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, and hopefully improve the Guile debugging
> experience? :-)

Despite what I wrote, I think it’s a good idea.  I suppose inspiration
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.

Ludo’.

Guile debugger workgroup? (was: Coding style: similarly-named variables)

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi Maxim,
>
> On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer  
> wrote:
>
>> In practice since using breakpoints/a debugger to debug Guile code
>> rarely works as intended (in my experience hacking on Guix!), we
>> typically sprinkle the source with 'pk', and that point becomes moot.
>
> I totally agree!  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 [1] – where it is easy to compare each intermediary result in
> the debugger.  For what it is worth, I have not been able to have some
> similar inspections as in [1].  Maybe, I am missing something…
>
> Well, IMHO, we are somehow suffering from some Guile limitations and
> improvements in this area are an hard task.

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, and hopefully improve the Guile debugging
experience? :-)

-- 
Thanks,
Maxim