[GH-ISSUE #491] How should I debug #204

New issue

Open

opened 2026-02-28 14:47:44 +03:00 by kerem · 2 comments

kerem commented

2026-02-28 14:47:44 +03:00

Owner

Originally created by @tysaya123 on GitHub (Jun 6, 2020).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/491

So I was hoping to start messing around with the code here. However, I am unsure what the best way to debug any changes I make is. Just wanted to ask if there is an easy way to debug the application?

Originally created by @tysaya123 on GitHub (Jun 6, 2020). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/491 So I was hoping to start messing around with the code here. However, I am unsure what the best way to debug any changes I make is. Just wanted to ask if there is an easy way to debug the application?

kerem commented

2026-02-28 14:47:44 +03:00

Author

Owner

@Rigellute commented on GitHub (Jun 29, 2020):

So sorry for late response @tysaya123.

I pretty much entirely rely on the power of the Rust compiler for debugging - I let the types do most of the work.

Is there something in particular that you need help debugging?

@Rigellute commented on GitHub (Jun 29, 2020): So sorry for late response @tysaya123. I pretty much entirely rely on the power of the Rust compiler for debugging - I let the types do most of the work. Is there something in particular that you need help debugging?

kerem commented

2026-02-28 14:47:45 +03:00

Author

Owner

@Utagai commented on GitHub (Oct 10, 2020):

I'm a print-statement kind of guy. When I worked on #604, I used a eprintln!() calls and just ran spt with its stderr redirected to a "log file":

$ spt 2> log.txt

and in a separate terminal:

$ tail -f log.txt

This let me use the UI while getting clean console output for when I needed to figure things out. This was mostly useful when I first started messing with the code and needed to confirm what the codepaths in the app were like. Prints help me confirm the flow.

I agree with @Rigellute that once I understood the code paths, I didn't really need to print much else to reason about and implement changes.

@Utagai commented on GitHub (Oct 10, 2020): I'm a print-statement kind of guy. When I worked on #604, I used a `eprintln!()` calls and just ran `spt` with its `stderr` redirected to a "log file": ``` $ spt 2> log.txt ``` and in a separate terminal: ``` $ tail -f log.txt ``` This let me use the UI while getting clean console output for when I needed to figure things out. This was mostly useful when I first started messing with the code and needed to confirm what the codepaths in the app were like. Prints help me confirm the flow. I agree with @Rigellute that once I understood the code paths, I didn't really need to print much else to reason about and implement changes.