[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A Guile debugger workgroup?
Re: A Guile debugger workgroup?
Tue, 29 Nov 2022 21:18:23 +0100
i almost never use a debugger but in C as a student.
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...
but this is my personal opinion :-)
On Tue, Nov 29, 2022 at 6:21 PM Olivier Dion via Developers list for Guile, the GNU extensibility library <firstname.lastname@example.org
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
which is a reply to <https://issues.guix.gnu.org/issue/58812#id=33>.
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
1. Documentation on debugging should be improved. e.g. The `pk`
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
5. Maybe not make a debugger with a paradigm for language like C but
instead take inspiration from other Scheme implementation like
Resume start here:
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.
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
2. Lack of debugger integration to an IDE (it's not even integrated
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
Well, Guile has a debugger that lets you do that [...] Geiser is not
Visual Studio™ but it does a good job.
Also, [...] I mentioned before that I almost never use breakpoints on
Guile code [...] 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.
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.
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’ way putting ’pk’ here or there,
right? One thing when debugging is to inspect the current state of
the program; [...] And, ’pk’ 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
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.
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.
[...] that brings us back to Maxim’s suggestion of starting a
[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.
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.
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.