Debug setup in emacs

Debug setup in emacs

[Fredrik Salomonsson]

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

Re: Debug setup in emacs

[Joshua Branson via General Guile related discussions]

When you figure out how to do it, please let me know.  :)

-- 
Joshua Branson
Sent from Emacs and Gnus

Re: Debug setup in emacs

[Jan Nieuwenhuizen]

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

Re: Debug setup in emacs

[Fredrik Salomonsson]

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

Re: Debug setup in emacs

[Jan Nieuwenhuizen]

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

Re: Debug setup in emacs

[Fredrik Salomonsson]

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

Re: Debug setup in emacs

[Catonano]

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

Re: Debug setup in emacs

[Fredrik Salomonsson]

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

Re: Debug setup in emacs

[Catonano]

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 😶

Re: Debug setup in emacs

[Zelphir Kaltstahl]

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

Re: Debug setup in emacs

[Fredrik Salomonsson]

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

Re: Debug setup in emacs

[Fredrik Salomonsson]

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