You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DevTools have this[1] new cool feature called "inline breakpoints".
Unfortunately it is implemented in a way which does not work well with source-mapped clojurescript-generated javascript code. I'm not sure where exactly their code fails but from brief review of the code it looks like they assume lines are fundamental code blocks for scanning for possible breakpoints. While this is true in javascript, it is not the case in clojurescript-generated javascript code. Typically one form in clojurescript code can span multiple lines and compiles into many more lines of javascript. Detection of possible breakpoints examines only first line (or first few lines) of generated javascript code which is usually not sufficient. There may be also some woes caused by source-mapping.
We should examine possibility of fixing this. I believe all low-level tools are available, we just need to scan whole raw source code generated for selected form. For example placing a breakpoint into gutter at some line, we should detect outer-most cljs form beginning on that line, properly find its end possibly many lines down from it. Then map both to raw javascript locations to get proper range for possible breakpoints scan. Then we must make sure that detected possible breakpoints are properly presented in the UI.
DevTools have this[1] new cool feature called "inline breakpoints".
Unfortunately it is implemented in a way which does not work well with source-mapped clojurescript-generated javascript code. I'm not sure where exactly their code fails but from brief review of the code it looks like they assume lines are fundamental code blocks for scanning for possible breakpoints. While this is true in javascript, it is not the case in clojurescript-generated javascript code. Typically one form in clojurescript code can span multiple lines and compiles into many more lines of javascript. Detection of possible breakpoints examines only first line (or first few lines) of generated javascript code which is usually not sufficient. There may be also some woes caused by source-mapping.
We should examine possibility of fixing this. I believe all low-level tools are available, we just need to scan whole raw source code generated for selected form. For example placing a breakpoint into gutter at some line, we should detect outer-most cljs form beginning on that line, properly find its end possibly many lines down from it. Then map both to raw javascript locations to get proper range for possible breakpoints scan. Then we must make sure that detected possible breakpoints are properly presented in the UI.
[1] https://umaar.com/dev-tips/129-inline-breakpoints/
The text was updated successfully, but these errors were encountered: