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

Make evaluation/cache return variables instead of what they point to (for def/defn) #47

Merged
merged 11 commits into from
Jan 12, 2022

Conversation

philomates
Copy link
Contributor

We'd like to allow for different ways to run and render tests from within notebooks.
clojure.test's deftest defines a variable with a :test metadata field present. It would be great to have this at render time, but clerk currently resolves variables returned by def and defn into what they point to. The changes here defer this resolution to the viewer so that we can add a viewer that checks for test meta-data and either hides or executes and shows results. We still don't want to resolve normal vars (that are the result of non-def/defn expression evaluation), so I introduced a wrapped-var to distinguish between the two.

The PR also:

  • adds test coverage for read+eval-cached
  • breaks up read+eval-cached into smaller functions. Let me if I went too overboard here; many well-named and small functions helps me with code readability but that might be the case for everyone.

open issues to be resolved:

  • rendering definition that returns a different var is broken
  • rendering deftest results in a string result when it should be render a function

20220106_16h18m54s_grim

(when (and (not no-cache?) (cachable-value? var-value))
(cache! digest-file var-value))
(let [blob-id (cond no-cache? (view/->hash-str var-value)
(fn? var-value) nil
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do functions get no hash, but other non-cachable things do get hashes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because Clojure functions cannot be (de-)serialized.

@mk
Copy link
Member

mk commented Jan 7, 2022

The printing issues should be resolved with dd19391:
CleanShot 2022-01-07 at 11 24 18@2x

Dropping the :render-fn key solved it and the :transform-fn doesn't need to be quoted.

@@ -351,7 +355,8 @@
(let [{:as opts :keys [viewers path offset]} (merge {:offset 0} opts)
wrapped-value (try (wrapped-with-viewer xs viewers) ;; TODO: respect `viewers` on `xs`
(catch #?(:clj Exception :cljs js/Error) _ex
nil))
(do (println _ex)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding this print helped me catch an issue that required adc43c4 and then the 6dea81e follow-up

(let [value (or (get results-last-run hash)
(thaw-from-cas cas-hash))]
(when (and introduced-var (not (::var-from-def value)))
(intern *ns* (-> introduced-var symbol name symbol) value))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the results-last-run for (def x 1) will point to {::var-from-def #'x} and then without the (not (::var-from-def value)) we would (intern *ns* #'x {::var-from-def #'x}) which causes the viewer code to stackoverflow when it it tries to display this var.

I'm unsure what the best approach to caching vars that we want to leave unresolved until viewer time (to allow for test running for example). So I just added a skip here. I think that the cache-to-filesystem code still caches the var->value even if it comes from a def, we just never use it.

@philomates philomates force-pushed the make-cache-return-vars branch from c08f6a7 to 15b4795 Compare January 11, 2022 10:43
@mk mk merged commit c352cad into main Jan 12, 2022
@mk mk deleted the make-cache-return-vars branch January 12, 2022 11:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants