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.