3 ms·

How debuggable is this (besides sifting through wall of debug log text)? Can you step through your declarative GUI building process inside DSL or its like this:

How debuggable is this (besides sifting through wall of debug log text)? Can you step through your declarative GUI building process inside DSL or its like this: "DSL text goes into magic magic...POOF! here is the result. hopefully nothing went wrong or glhf"

chao- 2y ago
The popular debugger for Ruby is a combination of two libraries: byebug and pry. Using these should allow you to step into/over code in a familiar way, if you've used most breakpoint-based debuggers. If you end up giving it a try, please report back!
- 3ds 2y ago
  These two gems have been superseded by the `debug` gem. https://github.com/ruby/debug https://github.com/ruby/debug
  - runako 2y ago
    Could you say more about that? I have been using pry, and it appears to still be updated. Is there a reason to stop using pry, or are you expressing a preference for the official debug gem? Thanks!
    - celdon25 2y ago
      Seems like the latter to me. One or the other gem is fine depending on your preferred interface.
verdverm 2y ago
I've built a DSL engine on top of CUE + Go's text/template [1]. This largely becomes feeding data into a set of templates, and even this can be hard to debug because template engines often lack the extras needed to support it. I'd be curious to see if a more code based DSL engine has better debug support. I would imagine you would be stepping through both the DSL code and the engine, if it is more dynamic (i.e. there is not a two step process for DSL authoring) What I like about a text/template engine is that anyone can use it (create new DSLs) without knowing the language the engine is implemented in. CUE appeals to me as the language for writing/using the DSL because (1) I don't have to learn a new syntax per DSL and (2) it becomes data (json/yaml) I can use anywhere for other purposes beyond generating code. [1] https://github.com/hofstadter-io/hof https://github.com/hofstadter-io/hof
- artemonster 2y ago
  my experience with interpreter pattern is that you will be spending 90% of debugger time stepping through abstract "eval" functions that are irrelevant to what you want debug.
  - sitkack 2y ago
    I solved this by writing code to walk the stack and extract the information I needed (this was Python, but am sure it would translate to Ruby).

chao- 2y ago

The popular debugger for Ruby is a combination of two libraries: byebug and pry. Using these should allow you to step into/over code in a familiar way, if you've used most breakpoint-based debuggers. If you end up giving it a try, please report back!

3ds 2y ago
These two gems have been superseded by the `debug` gem. https://github.com/ruby/debug https://github.com/ruby/debug
- runako 2y ago
  Could you say more about that? I have been using pry, and it appears to still be updated. Is there a reason to stop using pry, or are you expressing a preference for the official debug gem? Thanks!
  - celdon25 2y ago
    Seems like the latter to me. One or the other gem is fine depending on your preferred interface.

verdverm 2y ago

I've built a DSL engine on top of CUE + Go's text/template [1]. This largely becomes feeding data into a set of templates, and even this can be hard to debug because template engines often lack the extras needed to support it. I'd be curious to see if a more code based DSL engine has better debug support. I would imagine you would be stepping through both the DSL code and the engine, if it is more dynamic (i.e. there is not a two step process for DSL authoring) What I like about a text/template engine is that anyone can use it (create new DSLs) without knowing the language the engine is implemented in. CUE appeals to me as the language for writing/using the DSL because (1) I don't have to learn a new syntax per DSL and (2) it becomes data (json/yaml) I can use anywhere for other purposes beyond generating code. [1] https://github.com/hofstadter-io/hof https://github.com/hofstadter-io/hof

artemonster 2y ago
my experience with interpreter pattern is that you will be spending 90% of debugger time stepping through abstract "eval" functions that are irrelevant to what you want debug.
- sitkack 2y ago
  I solved this by writing code to walk the stack and extract the information I needed (this was Python, but am sure it would translate to Ruby).