* Debug setup in emacs @ 2020-09-04 23:37 Fredrik Salomonsson 2020-09-05 6:23 ` Joshua Branson via General Guile related discussions ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Fredrik Salomonsson @ 2020-09-04 23:37 UTC (permalink / raw) To: guile-user Hi, I've been playing around with guile for awhile and really liking it. One thing I haven't figured out is how to setup a good debugging environment in emacs, similar to edebug for elisp or gdb i.e. have a buffer that shows me were I am in the code. The manual (from what I have found) only shows me how to run that in a REPL. And I didn't find much when searching in the mailing archive. Is there a way to set this up or is the REPL the way to go? I'm currently using guile-2.2.7 and I'm using guile-hall-0.3.1 [1] for building and running my tests. Thanks [1] https://gitlab.com/a-sassmannshausen/guile-hall -- s/Fred[re]+i[ck]+/Fredrik/g ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-04 23:37 Debug setup in emacs Fredrik Salomonsson @ 2020-09-05 6:23 ` Joshua Branson via General Guile related discussions 2020-09-05 7:27 ` Jan Nieuwenhuizen 2020-09-06 7:19 ` Catonano 2 siblings, 0 replies; 12+ messages in thread From: Joshua Branson via General Guile related discussions @ 2020-09-05 6:23 UTC (permalink / raw) To: guile-user When you figure out how to do it, please let me know. :) -- Joshua Branson Sent from Emacs and Gnus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-04 23:37 Debug setup in emacs Fredrik Salomonsson 2020-09-05 6:23 ` Joshua Branson via General Guile related discussions @ 2020-09-05 7:27 ` Jan Nieuwenhuizen 2020-09-05 22:17 ` Fredrik Salomonsson 2020-09-06 7:19 ` Catonano 2 siblings, 1 reply; 12+ messages in thread From: Jan Nieuwenhuizen @ 2020-09-05 7:27 UTC (permalink / raw) To: Fredrik Salomonsson; +Cc: guile-user Fredrik Salomonsson writes: Hello, > I've been playing around with guile for awhile and really liking it. One > thing I haven't figured out is how to setup a good debugging environment > in emacs, similar to edebug for elisp or gdb i.e. have a buffer that > shows me were I am in the code. Some years ago, I created Guile mode for Emacs GUD and an initial patch for the guile debugger to work with that https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00004.html At the time, the guile debugger had a couple of bugs wrt setting breakpoints and I'm afraid the code has bitrotted since then. Greetings, Janneke -- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-05 7:27 ` Jan Nieuwenhuizen @ 2020-09-05 22:17 ` Fredrik Salomonsson 2020-09-06 5:43 ` Jan Nieuwenhuizen 0 siblings, 1 reply; 12+ messages in thread From: Fredrik Salomonsson @ 2020-09-05 22:17 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: guile-user Hi Jan, Jan Nieuwenhuizen <janneke@gnu.org> writes: > Some years ago, I created Guile mode for Emacs GUD and an initial > patch for the guile debugger to work with that > > https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00004.html > > At the time, the guile debugger had a couple of bugs wrt setting > breakpoints and I'm afraid the code has bitrotted since then. That sounds exactly what I'm after. Did any of that get merged upstream? As I see guiler mentioned in the Emacs GUD docs [1]. [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Starting-GUD.html#Starting-GUD -- s/Fred[re]+i[ck]+/Fredrik/g ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-05 22:17 ` Fredrik Salomonsson @ 2020-09-06 5:43 ` Jan Nieuwenhuizen 2020-09-07 19:50 ` Fredrik Salomonsson 0 siblings, 1 reply; 12+ messages in thread From: Jan Nieuwenhuizen @ 2020-09-06 5:43 UTC (permalink / raw) To: Fredrik Salomonsson; +Cc: guile-user Fredrik Salomonsson writes: Hello Fredrik, > Jan Nieuwenhuizen <janneke@gnu.org> writes: > >> Some years ago, I created Guile mode for Emacs GUD and an initial >> patch for the guile debugger to work with that >> >> https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00004.html >> >> At the time, the guile debugger had a couple of bugs wrt setting >> breakpoints and I'm afraid the code has bitrotted since then. > > That sounds exactly what I'm after. Did any of that get merged > upstream? As I see guiler mentioned in the Emacs GUD docs [1]. Yes, the Emacs side got merged, try: M-x guiler RET That was perhaps a bit premature, but Guile and Emacs had to be patched in balance and I didn't expect the Guile side to be problematic. The good news is that "someone" "only needs" to create a proper patch for Guile :-) Janneke -- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-06 5:43 ` Jan Nieuwenhuizen @ 2020-09-07 19:50 ` Fredrik Salomonsson 0 siblings, 0 replies; 12+ messages in thread From: Fredrik Salomonsson @ 2020-09-07 19:50 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: guile-user Jan Nieuwenhuizen <janneke@gnu.org> writes: > Yes, the Emacs side got merged, try: M-x guiler RET > > That was perhaps a bit premature, but Guile and Emacs had to be patched > in balance and I didn't expect the Guile side to be problematic. > > The good news is that "someone" "only needs" to create a proper patch > for Guile :-) Yeah, I tried using it but got stuck on trying to load the correct environment for my program to work. But didn't spend too much time on it. And given the answer from Catonano, this seems to be more complex than I first thought. So will wait until that "someone" creates the necessary patches :). -- s/Fred[re]+i[ck]+/Fredrik/g ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-04 23:37 Debug setup in emacs Fredrik Salomonsson 2020-09-05 6:23 ` Joshua Branson via General Guile related discussions 2020-09-05 7:27 ` Jan Nieuwenhuizen @ 2020-09-06 7:19 ` Catonano 2020-09-07 20:01 ` Fredrik Salomonsson 2 siblings, 1 reply; 12+ messages in thread From: Catonano @ 2020-09-06 7:19 UTC (permalink / raw) To: Fredrik Salomonsson; +Cc: Guile User Hi Fredrik, Il giorno sab 5 set 2020 alle ore 02:53 Fredrik Salomonsson < plattfot@posteo.net> ha scritto: > > Hi, > > I've been playing around with guile for awhile and really liking it. One > thing I haven't figured out is how to setup a good debugging environment > in emacs, similar to edebug for elisp or gdb i.e. have a buffer that > shows me were I am in the code. > > The manual (from what I have found) only shows me how to run that in a > REPL. And I didn't find much when searching in the mailing archive. Is > there a way to set this up or is the REPL the way to go? > > I'm currently using guile-2.2.7 and I'm using guile-hall-0.3.1 [1] for > building and running my tests. > > Thanks > > [1] https://gitlab.com/a-sassmannshausen/guile-hall > > -- > s/Fred[re]+i[ck]+/Fredrik/g > > you already received an answer about the integration between the Guile debugger and Emacs GUD I'd like to illuminate a different point here The Guile debugger currently isn't able to show local variables in many cases So even if you could achieve full integration between it and Emacs GUD, you probably still wouldn't get full information in your GUD based human interface That is, the guile debugger in its current incarnation is broken, it doesn't debug The reason why this happens is explained, to some extent, in a post by Andy Wingo on his blog about some tasks to improve the compiler he'd like to have implemented, it's here (read the "basic register allocation" task) https://wingolog.org/archives/2016/02/04/guile-compiler-tasks In a more recent post, Andy extended his argument on the implementation of debugging https://wingolog.org/archives/2018/02/07/design-notes-on-inline-caches-in-guile This is a relevant paragraph "Honestly I struggle a lot with the idea of debugging native code. GDB does the least-overhead, most-generic thing, which is patching code directly; but it runs from a separate process, and in Guile we need in-process portable debugging. The debugging use case is a clear area where you want adaptive optimization, so that you can emit debugging ceremony from the hottest code, knowing that you can fall back on some earlier tier. Perhaps Guile should bite the bullet and go this way too." So there seem to be deep reasons that have to do with optimization, runtime support for offering a full debugging experience in Guile Anyway, the info I want to convey is that even of you manage to have the communication between the Guile debugger and Emacs GUD set up, you still might be disappointed by the result I think it's important that you know this before pouring effort in having your GUD based thing going ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-06 7:19 ` Catonano @ 2020-09-07 20:01 ` Fredrik Salomonsson 2020-09-08 6:15 ` Catonano 0 siblings, 1 reply; 12+ messages in thread From: Fredrik Salomonsson @ 2020-09-07 20:01 UTC (permalink / raw) To: Catonano; +Cc: Guile User Hi Catonano, Catonano <catonano@gmail.com> writes: > you already received an answer about the integration between the Guile > debugger and Emacs GUD > > I'd like to illuminate a different point here > > The Guile debugger currently isn't able to show local variables in many > cases > > So even if you could achieve full integration between it and Emacs GUD, you > probably still wouldn't get full information in your GUD based human > interface > > That is, the guile debugger in its current incarnation is broken, it > doesn't debug > > The reason why this happens is explained, to some extent, in a post by Andy > Wingo on his blog about some tasks to improve the compiler he'd like to > have implemented, > > it's here (read the "basic register allocation" task) > https://wingolog.org/archives/2016/02/04/guile-compiler-tasks > > In a more recent post, Andy extended his argument on the implementation of > debugging > https://wingolog.org/archives/2018/02/07/design-notes-on-inline-caches-in-guile > > This is a relevant paragraph > > "Honestly I struggle a lot with the idea of debugging native code. GDB does > the least-overhead, most-generic thing, which is patching code directly; > but it runs from a separate process, and in Guile we need in-process > portable debugging. The debugging use case is a clear area where you want > adaptive optimization, so that you can emit debugging ceremony from the > hottest code, knowing that you can fall back on some earlier tier. Perhaps > Guile should bite the bullet and go this way too." > > So there seem to be deep reasons that have to do with optimization, runtime > support for offering a full debugging experience in Guile > Thank you for pointing this out to me and the links to the blog posts. > Anyway, the info I want to convey is that even of you manage to have the > communication between the Guile debugger and Emacs GUD set up, you still > might be disappointed by the result > > I think it's important that you know this before pouring effort in having > your GUD based thing going Yeah, I didn't expect it to be that complicated to have that setup. I'll put my focus on learning the language first, and leave the perfect debug setup for later. Right now sprinkling (format #t) in the code kind of works. And as a follup question. What do people use when debugging guile code? Thanks again. -- s/Fred[re]+i[ck]+/Fredrik/g ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-07 20:01 ` Fredrik Salomonsson @ 2020-09-08 6:15 ` Catonano 2020-09-08 6:45 ` Zelphir Kaltstahl 2020-09-08 17:07 ` Fredrik Salomonsson 0 siblings, 2 replies; 12+ messages in thread From: Catonano @ 2020-09-08 6:15 UTC (permalink / raw) To: Fredrik Salomonsson; +Cc: Guile User Hi Fredrik, Il giorno lun 7 set 2020 alle ore 22:01 Fredrik Salomonsson < plattfot@posteo.net> ha scritto: > > Thank you for pointing this out to me and the links to the blog posts. > > My pleasure ☺ And as a follup question. What do people use when debugging guile code? > > I don't debug much, personally I know some people have been using the "pk" procedure It displays the arguments you pass to it in the terminal and returns the same arguments, untouched So you can sprinkle it all around I've had my issues with it though I never tried with (format #f) as you suggested Also, there's the "trace tool (try "(help) in the repl to read about it) This is all I know Maybe someone else can chime in, here Also, I'm wondering if this issue doesn't deserve a thread on its own 😶 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-08 6:15 ` Catonano @ 2020-09-08 6:45 ` Zelphir Kaltstahl 2020-09-08 17:18 ` Fredrik Salomonsson 2020-09-08 17:07 ` Fredrik Salomonsson 1 sibling, 1 reply; 12+ messages in thread From: Zelphir Kaltstahl @ 2020-09-08 6:45 UTC (permalink / raw) To: Fredrik Salomonsson; +Cc: Guile User Hi Frederik! I usually find myself using (display (simple-format #f "blablabla: ~a\n some-binding)) or a custom procedure wrapping it. At some point it becomes too much and I switch to the REPL and trying things in there, if the setup or situation is not too hard to reproduce. Also used (pk ...) sometimes, when I am not sure an expression is ever evaluated. If this fails me, I sometimes try to think about all the custom procedures involved and start writing tests. If I am too lazy to do that, I find myself thinking about the problem real hard and then usually facepalming about my own silly mistakes. If I still don't know what's going on, I might ask on the mailing list for help. Regards, Zelphir On 08.09.20 08:15, Catonano wrote: > Hi Fredrik, > > Il giorno lun 7 set 2020 alle ore 22:01 Fredrik Salomonsson < > plattfot@posteo.net> ha scritto: > >> Thank you for pointing this out to me and the links to the blog posts. >> >> > My pleasure ☺ > > > And as a follup question. What do people use when debugging guile code? >> > I don't debug much, personally > > I know some people have been using the "pk" procedure > > It displays the arguments you pass to it in the terminal and returns the > same arguments, untouched > > So you can sprinkle it all around > > I've had my issues with it though > > I never tried with (format #f) as you suggested > > Also, there's the "trace tool (try "(help) in the repl to read about it) > > This is all I know > > Maybe someone else can chime in, here > > Also, I'm wondering if this issue doesn't deserve a thread on its own 😶 -- repositories: https://notabug.org/ZelphirKaltstahl ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-08 6:45 ` Zelphir Kaltstahl @ 2020-09-08 17:18 ` Fredrik Salomonsson 0 siblings, 0 replies; 12+ messages in thread From: Fredrik Salomonsson @ 2020-09-08 17:18 UTC (permalink / raw) To: Zelphir Kaltstahl; +Cc: Guile User Hi Zelphir, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: > I usually find myself using (display (simple-format #f "blablabla: ~a\n > some-binding)) or a custom procedure wrapping it. You might want to try (simple-format #t "blablabla: ~a\n some-binding) instead. The #t will send it to the current output port, so it will do the same as the above. just less to type :). > At some point it becomes too much and I switch to the REPL and trying > things in there, if the setup or situation is not too hard to reproduce. > Also used (pk ...) sometimes, when I am not sure an expression is ever > evaluated. Yeah, definetly need to check out the "pk" procedure. Seems quite useful. > If this fails me, I sometimes try to think about all the custom > procedures involved and start writing tests. > > If I am too lazy to do that, I find myself thinking about the problem > real hard and then usually facepalming about my own silly mistakes. Writing tests + sprinkle (format #t ...) and thinking hard about the problem is what I've been doing to find all my own silly mistakes. > If I still don't know what's going on, I might ask on the mailing list > for help. Thanks for the input! -- s/Fred[re]+i[ck]+/Fredrik/g ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Debug setup in emacs 2020-09-08 6:15 ` Catonano 2020-09-08 6:45 ` Zelphir Kaltstahl @ 2020-09-08 17:07 ` Fredrik Salomonsson 1 sibling, 0 replies; 12+ messages in thread From: Fredrik Salomonsson @ 2020-09-08 17:07 UTC (permalink / raw) To: Catonano; +Cc: Guile User Hi Catonano, Catonano <catonano@gmail.com> writes: > I know some people have been using the "pk" procedure > > It displays the arguments you pass to it in the terminal and returns the > same arguments, untouched > > So you can sprinkle it all around > > I've had my issues with it though I didn't know about the "pk" procedure, that seems useful. Thanks > Also, there's the "trace tool (try "(help) in the repl to read about it) > > This is all I know Yeah, I've seen the trace command flying by when I jump around in the manual. Will check it out. > Also, I'm wondering if this issue doesn't deserve a thread on its own > 😶 Yeah, it probably does, instead of getting burried in this emacs thread. -- s/Fred[re]+i[ck]+/Fredrik/g ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-09-08 17:18 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-04 23:37 Debug setup in emacs Fredrik Salomonsson 2020-09-05 6:23 ` Joshua Branson via General Guile related discussions 2020-09-05 7:27 ` Jan Nieuwenhuizen 2020-09-05 22:17 ` Fredrik Salomonsson 2020-09-06 5:43 ` Jan Nieuwenhuizen 2020-09-07 19:50 ` Fredrik Salomonsson 2020-09-06 7:19 ` Catonano 2020-09-07 20:01 ` Fredrik Salomonsson 2020-09-08 6:15 ` Catonano 2020-09-08 6:45 ` Zelphir Kaltstahl 2020-09-08 17:18 ` Fredrik Salomonsson 2020-09-08 17:07 ` Fredrik Salomonsson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).