Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug decorations are breaking after stepping through code during debug session #669

Closed
bpringe opened this issue Jun 14, 2020 · 1 comment · Fixed by #671
Closed

Debug decorations are breaking after stepping through code during debug session #669

bpringe opened this issue Jun 14, 2020 · 1 comment · Fixed by #671
Labels
bug Something isn't working debugger

Comments

@bpringe
Copy link
Member

bpringe commented Jun 14, 2020

Steps to reproduce:

  1. Instrument a function for debugging
  2. Call the function
  3. Step through the function until evaluation is complete (F10)
  4. Try to evaluate the function regularly to remove the instrumentation and notice that the decorations do not disappear as they should

The following error appears in the debug console when running calva in debug mode and after performing the above steps:

stack trace: Error: The map literal starting with :filename contains 7 form(s). Map literals must contain an even number of forms.
    at new cljs$core$ExceptionInfo (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/core.cljs:11332:1)
    at Function.cljs$core$IFn$_invoke$arity$3 (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/core.cljs:11361:1)
    at Function.cljs$core$IFn$_invoke$arity$2 (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/core.cljs:11361:1)
    at Function.cljs$core$IFn$_invoke$arity$variadic (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/impl/errors.cljs:29:3)
    at Function.cljs$core$IFn$_invoke$arity$variadic (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/impl/errors.cljs:39:1)
    at Object.cljs$tools$reader$impl$errors$throw_odd_map [as throw_odd_map] (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/impl/errors.cljs:70:1)
    at cljs$tools$reader$edn$read_map (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:200:5)
    at Object.cljs$tools$reader$edn$read_delimited [as read_delimited] (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:175:11)
    at cljs$tools$reader$edn$read_vector (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:188:1)
    at Object.the-map [as read_delimited] (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:175:11)
    at cljs$tools$reader$edn$read_map (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:196:9)
    at Function.cljs$core$IFn$_invoke$arity$4 (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:411:23)
    at Function.cljs$core$IFn$_invoke$arity$2 (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:399:6)
    at Function.cljs$core$IFn$_invoke$arity$2 (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/tools/reader/edn.cljs:447:6)
    at Function.cljs$core$IFn$_invoke$arity$2 (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/cljs/reader.cljs:174:1)
    at Object.calva$parse$parse_edn [as parse_edn] (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/calva/parse.cljs:9:1)
    at Object.calva$parse$parse_edn_js [as parse_edn_js] (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/calva/parse.cljs:21:1)
    at calva$parse$parse_edn_js_bridge (/home/brandon/development/calva/.shadow-cljs/builds/calva-lib/dev/out/cljs-runtime/calva/parse.cljs:24:1)
    at /home/brandon/development/calva/src/debugger/decorations.ts:27:12
    at Generator.next (<anonymous>)
    at fulfilled (/home/brandon/development/calva/out/debugger/decorations.js:5:58)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
extensionHostProcess.js:976

Right before the above error is thrown, if you put a breakpoint at the return line of this function in decorations.ts,

async function getLintAnalysis(session: NReplSession, documentText: string): Promise<any> {
    const code = `(with-in-str ${JSON.stringify(documentText)} (:analysis (clj-kondo.core/run! {:lint ["-"] :lang :clj :config {:output {:analysis true}}})))`;
    const resEdn = await session.eval(code, 'user').value;
    return parseEdn(resEdn);
}

when execution pauses there you will see that resEdn looks like it was printed with a short *print-length* value.

"{:namespace-definitions [{:filename "<stdin>", :row 1, :col 1, ...}], :namespace-usages [{:filename "<stdin>", :row 2, :col 14, ...} {:filename "<stdin>", :row 3, :col 14, ...}], :var-definitions [{:filename "<stdin>", :row 5, :col 1, ...} {:filename "<stdin>", :row 10, :col 1, ...} {:filename "<stdin>", :row 13, :col 1, ...} ...], ...}"

This results in the error mentioned above because of {:filename "<stdin>", :row 1, :col 1, ...}.

Before the error happens, resEdn contains unshortened/full results. So we need to figure out what is causing the switch to shortened results. Is something setting *print-length*?

@bpringe bpringe added bug Something isn't working debugger labels Jun 14, 2020
@bpringe
Copy link
Member Author

bpringe commented Jun 14, 2020

I think I see where I broke this 😄 🤦 . I somehow left some code in that I was trying out at some point, or so it seems.

await cljSession.eval('(set! clojure.core/*print-length* 3)', 'user').value;

This is related to #631. I just need to remove that line, but I'm about to be afk for a while and may not be able to get to it until later tonight or tomorrow.

Also this makes me realize that we should probably set *print-length* to false and then back to what it was before inside getLintAnalysis so that when the user sets *print-length* it doesn't break debug decorations.

@bpringe bpringe changed the title Debug decorations are breaking after completed debug session Debug decorations are breaking after stepping through code during debug session Jun 15, 2020
bpringe added a commit that referenced this issue Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working debugger
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant