Hi! I have a personal notes project based off clerk-demo, which I upgraded to use the latest clerk recently (`0.15.957`).
I noticed that often (but not always) after I save a watched .clj file, the web page will first update and then jump to the index page.
Anyone else seeing the same?
Did I mess something up in my deps.edn: https://github.com/a1exsh/notes/blob/main/deps.edn#L12-L21 ?
I the repl I see unexpected Clerk evaluated 'jar:file:/home/ash/.m2/repository/io/github/nextjournal/clerk/0.15.957/clerk-0.15.957.jar!/nextjournal/clerk/index.clj' in 79.353063ms. after it evals my file.
> hmm, not 100% sure either if this is intentional anymore @mkvlr The code path which reads from nextjournal/clerk alias in deps.edn is still there but is bypassed by this binding https://github.com/nextjournal/clerk/blob/f8377d6116ccecee00ecf1dcc2fa843555cac9d8/src/nextjournal/clerk.clj#L71-L72 I’ll file an issue.
@alex.shulgin @andrea712 fixed it with https://github.com/nextjournal/clerk/commit/01d8ecce5d5d6c4a6ce94b0e0138c4b79bd219ff
@alex.shulgin There will be breaking changes from time to time until version 1.0 ships. We’re still actively working on a number of details and APIs. Once things solidify, we’ll bring them under test, as we’ve been gradually doing for the parts we’re pretty sure are baked. In the meanwhile, I can only offer apologies for occasional annoyances.
@jackrusher that makes sense, I wouldn't want to trip over failing tests while evolving the API myself. Thanks once again! :)
@mkvlr @andrea712 is there a chance to cover this with a test, so that it doesn't break next time again?.. 😉 I'm really grateful for Clerk being there, but my experience is too often: - upgrade to the latest commit to fix an issue; - discover that something else doesn't work anymore; - repeat
Hi Alex, newer versions of Clerk update the shown notebook as a result of an url update in the browser. I believe what you’re seeing here might be a result of that. Is one of your notebooks maybe requesting a local file that could cause this?
or doing a request to /?
no, nothing like that. I've tried to inspect the requests that the webpage is doing and it suddenly stopped reproducing, but I got this error in the JS console:
Uncaught TypeError: URL constructor: is not a valid URL.
PL render.cljs:650
b render.cljs:723
aM render.cljs:721
Ela events.js:453
a events.js:213
yla listenermap.js:305
Lv listener.js:71
dM render.cljs:740
hM render.cljs:750
<anonymous> macros:432
render.cljs:650:5
PL render.cljs:650
b render.cljs:723
aM render.cljs:721
Ela events.js:453
a events.js:213
(Async: EventListener.handleEvent)
yla listenermap.js:305
Lv listener.js:71
dM render.cljs:740
hM render.cljs:750
<anonymous> macros:432this is the code and the line that fails:
@mkvlr does that look familiar to you? because I don't know where to look next
@alex.shulgin the code is public, right? How can I repro this?
yes, just clone it and then navigate to macros.clj, for example. for me it almost always results in render + redirect to index
navigate how?
haven’t been able to reproduce it yet
would recommend trying the latest git sha of clerk as well
tried the file watcher and running clerk show manually but failing to repro either way
what browser are you using?
Firefox
> navigate how?
from the index page after running serve!
let me try the latest commit though
so clicking here?
yep
also can’t repro in firefox
(latest git version greets me with this error on the index page):
Uncaught DOMException: An attempt was made to use an object that is not, or is no longer, usable
ws_send sci_env.cljs:220
HL render.cljs:561
h render.cljs:653
j render.cljs:536
hM render.cljs:725
Dla events.js:454
a events.js:216
viewer.js:5911can you try deleting the clerk cache?
with (clerk/clear-cache!)?
yep
not seeing the error
so far I didn't repro my original problem with the latest git
OK, but why this now?
I didn't change my :exec-args
hmm, not 100% sure either if this is intentional anymore, cc @andrea712
I think we did more guesswork previously to infer the :paths but have decided to stop doing that
but not 100% sure anymore
but I do specify them: https://github.com/a1exsh/notes/blob/main/deps.edn#L14 <= is that not correct?
this doesn’t also pass them to clerk/serve! try passing the same as a an arg
like so: (clerk/serve! {:paths ["src/*.clj"] :watch-paths ["src"] :port 6677 :browse? true}) ?
that has slightly different effects
namely, I don't get Home and Index pages at all this way
shouldn’t this be {:paths ["notebooks/*.clj"] ,,,?
sorry, context switching. let me try again %)
yeah, the same problem — it somehow jumps straight to macros and no Home or Index:
I see this
with the following command (clerk/serve! {:browse? true :port 6677 :paths ["notebooks/*.clj"]})
bummer, I removed the other two files locally while debugging the original issue. now I see the same
but where is the Home page now? that was useful
setting :paths intentionally disables it
Okay... no pressing issue at the moment, so I guess I can live with that. Thanks a lot for the tips! 🙂
Hm, it looks like top-to-bottom evaluation doesn't play along with forward declarations... Is there a trick that I'm missing?
@andrea712 can you comment — is this by design or a quirk? Should I rather open a github issue? 🙂
I don’t think this is intentional, but I might be wrong, @mkvlr any insights?
@alex.shulgin we had a related issue already, I added your remarks there https://github.com/nextjournal/clerk/issues/454
clerk should handle forward declarations, could you share some details of what’s going wrong for you?
I'll try to reproduce. What I observed was stale results from expressions that depend on the definition.
sounds like a caching issue
I remember thinking that and trying to clear the cache, but that was not helping. I'm generally doing my homework before complaining. ;)
Cannot reproduce it now in isolation. Will come back here if I hit it again.
There is one quirk though: https://github.clerk.garden/a1exsh/notes/commit/3e5f1a8b467784b9b4b8c96f423600b0a6d4e1fa/notebooks/declare/ I understand that Clerk is trying to be helpful (or is it accidental?), but the behavior is then different when actually evaluating top to bottom.