Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hi Simon, > > zimoun <zimon.touto...@gmail.com> writes: > >> Hi Maxim, >> >> On Mon, 21 Nov 2022 at 15:55, Maxim Cournoyer <maxim.courno...@gmail.com> >> 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.
