Hi again, I recently asked about something similar but more Emacs specific in the thread "Debug setup in Emacs". But it seems there are some more work to be done to get it properly hooked up with Emacs' GUD. I asked a follow up question how people debug their code and got as suggestion that it might be better to create a separate thread for it. So here it is. I'm fairly new with guile (hence why I ask about this). My workflow (in other languages) is usually to write tests, then when something goes wrong I hook up a debugger and step through the code. For guile I've been just writing tests and when something goes wrong I sprinkle (format #t ...) and re-run the tests. I haven't dabbled that much in running the REPL as I haven't figured out a good way of setting up the same environment as when I run the tests (using guile-hall). What I gathered from the "Debug setup in Emacs" thread. Is to sprinkle print out statements using the "format" or "simple-format" procedure. Use the "pk" procedure. Use the REPL if the setup is easy enough, combined with the use of trace. And to write tests. So I'm curious if there are other workflows/steps people use/take? Thanks -- s/Fred[re]+i[ck]+/Fredrik/g
Hi Fredrik! On 08.09.20 19:42, Fredrik Salomonsson wrote: > Hi again, > > I recently asked about something similar but more Emacs specific in the > thread "Debug setup in Emacs". But it seems there are some more work to > be done to get it properly hooked up with Emacs' GUD. I asked a follow > up question how people debug their code and got as suggestion that it > might be better to create a separate thread for it. > > So here it is. > > I'm fairly new with guile (hence why I ask about this). My workflow (in > other languages) is usually to write tests, then when something goes > wrong I hook up a debugger and step through the code. > > For guile I've been just writing tests and when something goes wrong I > sprinkle (format #t ...) and re-run the tests. I haven't dabbled that > much in running the REPL as I haven't figured out a good way of setting > up the same environment as when I run the tests (using guile-hall). I've not used guile-hall yet, nor tested with it. However, what I do to reproduce the same environment as I have in srfi-64 unit test, but inside the REPL is the following: 1. start the Guile REPL with `guile -L <dir where my module is>` 2. run `(use-modules (<my module name>))` 3. use procedures defined inside the module 4. copy and paste changed or new definitions from the code 5. try out the definitions and if something goes wrong fix it and go back to step 4 again If running M-x run-guile or M-x run-geiser from Emacs, one might need to change the %load-path of Guile. This can be done with `(add-to-load-path <string path to dir containing my module>)` for example. Then one can proceed as described above again. Not sure if any of this is new to you, but I guessed it would be good to put it out there. > What I gathered from the "Debug setup in Emacs" thread. Is to sprinkle > print out statements using the "format" or "simple-format" procedure. > > Use the "pk" procedure. > > Use the REPL if the setup is easy enough, combined with the use of > trace. > > And to write tests. > > So I'm curious if there are other workflows/steps people use/take? > > Thanks Regards, Zelphir -- repositories: https://notabug.org/ZelphirKaltstahl
Hey Fredrik ! I practice Test Driven Development to the point I make very small changes so I can manage the debugging part usually thanks to the pk command. Otherwise I call for help haha (love you, guilers) I have to say, I never worked on big projects so I don't have big requirements haha Cheers, Jérémy
Hi,
On Tue, Sep 8, 2020 at 10:43 AM Fredrik Salomonsson <plattfot@posteo.net>
wrote:
>
> Hi again,
>
> I recently asked about something similar but more Emacs specific in the
> thread "Debug setup in Emacs". But it seems there are some more work to
> be done to get it properly hooked up with Emacs' GUD. I asked a follow
> up question how people debug their code and got as suggestion that it
> might be better to create a separate thread for it.
>
> So here it is.
>
> I'm fairly new with guile (hence why I ask about this). My workflow (in
> other languages) is usually to write tests, then when something goes
> wrong I hook up a debugger and step through the code.
>
> For guile I've been just writing tests and when something goes wrong I
> sprinkle (format #t ...) and re-run the tests. I haven't dabbled that
> much in running the REPL as I haven't figured out a good way of setting
> up the same environment as when I run the tests (using guile-hall).
>
> What I gathered from the "Debug setup in Emacs" thread. Is to sprinkle
> print out statements using the "format" or "simple-format" procedure.
>
> Use the "pk" procedure.
>
> Use the REPL if the setup is easy enough, combined with the use of
> trace.
>
> And to write tests.
>
> So I'm curious if there are other workflows/steps people use/take?
>
>
>
I usually run Geiser with a REPL running and reevaluate any changes (C-c
C-k) and try again in the REPL. At the same time also use (pk) or
(display). And hopefully also run tests.
Aleix
Hi Zelphir, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes: > I've not used guile-hall yet, nor tested with it. It has some rough edges but keeps my focus away from hacking on build system files (which I tend to do far too much). So I'm digging it. > However, what I do to reproduce the same environment as I have in > srfi-64 unit test, but inside the REPL is the following: > > 1. start the Guile REPL with `guile -L <dir where my module is>` > 2. run `(use-modules (<my module name>))` > 3. use procedures defined inside the module > 4. copy and paste changed or new definitions from the code > 5. try out the definitions and if something goes wrong fix it and go > back to step 4 again > > If running M-x run-guile or M-x run-geiser from Emacs, one might need to > change the %load-path of Guile. This can be done with `(add-to-load-path > <string path to dir containing my module>)` for example. Then one can > proceed as described above again. > > Not sure if any of this is new to you, but I guessed it would be good to > put it out there. Thanks for the write up. I know most of the pieces, from reading the manual. But I'm still trying to piece them together so this is very helpful for me. Especially the "add-to-load-path" for geiser, as that is what I was missing. -- s/Fred[re]+i[ck]+/Fredrik/g