Re: Debugging Guix beyond pk (was Re: Notes from the Guix Days)

[Maxim Cournoyer]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> On ven., 17 mars 2023 at 11:07, Maxim Cournoyer <maxim.cournoyer@gmail.com> 
> wrote:
>
>>>   https://gitlab.com/pjotrp/guix-days-fosdem-2023/-/tree/main/
>>
>> This is nice, I just peeked at "Debugging Guix beyond pk".  I'll
>> bookmark and read more of it, thank you!
>
> I was very interested by this session, especially after the recent
> thread [1] about Guile debugger.  In that thread [1], Ludo wrote,
> quoting:
>
>         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.
>
> and that’s the conclusion I came back to home: the good ol’ ’pk’ is just
> the right tool for the job – considering the current state of Guile
> debugger as discussed in this thread [1].

I agree it's the "right" as in "best" tool for the job given the current
situation that makes stepping Guile code difficult/impossible to follow
or stop where one wants.  I still think a more user-friendly/capable
debugger would be nice, but haven't had the opportunity to take actions
yet.  The obvious low hanging fruit would be to start with documenting
'pk' in the Guile user manual :-).

> That’s said, the notes do not mention ’guix-derivation-mode’ from the
> package emacs-guix.  Well, last do not miss ’guix-scheme-mode’ which
> eases the reading of Scheme “builder” code – it is not always
> autoloaded.
>
> 1: https://yhetil.org/guix/87fse69czr.fsf@gnu.org

I know these, they are very useful.  Not too discoverable too, I reckon!
Thanks for pointing them out.

-- 
Thanks,
Maxim