Closed kkinnear closed 1 year ago
Hi @kkinnear, thanks for the detailed report, I shall take a peek!
Can reproduce your issue here with the current version of cljdoc-analyzer. Cljdoc-analyzer v1.0.759 (the previous version) analyzes zprint 1.2.7 just fine.
I'll dig into what is going on.
Hmmm... still digging.
A change I made delays the require
of ClojureScript analysis support to when/if needed.
This is somehow affecting sci workings under ClojureScript analysis. I don't understand why yet. If I revert this delayed require
analysis works.
Both sci and cljdoc-analyzer interact with the Clojurescript analyzer api... so... probably related somehow to that.. dunno yet... I'll keep looking.
I don't understand why, but if I move my delayed require
before any analysis begins, the analysis succeeds. I'll do that for now and dig deeper someday if necessary.
@kkinnear I've fixed the issue in cljdoc-analyzer, I'll ping back here when it has gone live for cljdoc.
@kkinnear the fix is now live!
Wow! @., that’s amazing. Thank you so much. I didn’t know that the local copy of cljdoc I have would update itself as new things were released. I hope to have time give it a spin tomorrow!Thanks again!On Sep 10, 2023, at 6:06 PM, Lee Read @.> wrote: @kkinnear the fix is now live!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
For you @kkinnear? My pleasure!
The cljdoc server is set up to always use the current release of cljdoc-analyzer.
Thanks again, @lread, for the extremely quick fix. It works great! I didn't know you had been working on cljdoc. It is a great service. It also uses zprint :-).
I'm guessing that this wasn't a common problem, but more likely (almost?) unique to zprint. If so, I wouldn't be surprised if the problem was related to the fact that zprint uses sci
internally, but that's just a guess.
As an aside, I saw the issue for cljdoc
about analyzing library API's statically, #543. I think zprint would be one of the ones that would work statically, for what that's worth.
Now I'm back in business trying to finish up the 1.2.8 release of zprint. Because @borkdude opened up some sci
code in babashka
recently, zprint 1.2.8 is now babashka
compatible. I've documented how people can run zprint as a task in babashka
or install it with bbin
.
Anyway, thanks again! It is always great to work with you.
Thanks again, @lread, for the extremely quick fix. It works great! I didn't know you had been working on cljdoc. It is a great service. It also uses zprint :-).
Yeah, I help out here and there on cljdoc! And zprint is a great choice for cljdoc to format edn presented to the user!
I'm guessing that this wasn't a common problem, but more likely (almost?) unique to zprint. If so, I wouldn't be surprised if the problem was related to the fact that zprint uses
sci
internally, but that's just a guess.
It was somehow sci
related but not sure how/why.
Both sci and cljdoc-analyzer use the ClojureScript analyzer, so some order of init/operations issue there somehow, I guess.
As an aside, I saw the issue for
cljdoc
about analyzing library API's statically, #543. I think zprint would be one of the ones that would work statically, for what that's worth.
Thanks for the tip, I've been slowly working on this over the long past while. I'll be sure to add zprint to my exploration suite.
Now I'm back in business trying to finish up the 1.2.8 release of zprint. Because @borkdude opened up some
sci
code inbabashka
recently, zprint 1.2.8 is nowbabashka
compatible. I've documented how people can run zprint as a task inbabashka
or install it withbbin
.
Cool!
Anyway, thanks again! It is always great to work with you.
The feeling is mutual!
I am totally confused by a cljdoc problem I have encountered.
Presenting problem:
All of my cljdoc local trial runs, as well as cljdoc-analyzer runs, yield:
It appears to successfully analyze the clj code, but fail on doing the cljs analysis (entire output available later):
Background:
I routinely run cljdoc locally to ensure that my docs will work with cljdoc when I push them to GitHub. This generally works fine, and for instance I successfully ran cljdoc locally on zprint 1.2.7 prior to releasing it. It worked locally. And, indeed, when I pushed 1.2.7, cljdoc successfully analyzed my code and docs and you can see the docs for zprint 1.2.7 work fine online with cljdoc today.
I have been doing the same thing while working on zprint 1.2.8, and it was working fine. I last had it work on Sept 1. On Sept 9, I was unable to get the analysis of the code to work (received the above error), no matter what I tried. I tried a newer version of cljdoc locally, no luck. I had done very little to the code in the intervening period, so I was quite surprised. I tried a lot to things, all to no avail.
I then tried to work with older jar files, thinking I had messed something up. Still, the same problem.
I cloned the 1.2.7 version off of GitHub into a new directory, and tried that. Same problem.
I then looked at cljdoc issues. Nothing obvious. I stumbled into cljdoc-analyzer. Maybe this would help, or give better errors, or something?
For what it is worth, I'm running on macOS on MacBook Air M1, using:
I installed it locally:
Then I built the jar in the cloned version of zprint, 1.2.7, with
and ran the analyzer on it:
and I get the same problem. When I look at my local cljdoc output for zprint 1.2.7, I see:
but when I look at the "real" cljdoc online, for zprint 1.2.7, I see that it works fine.
I've attached the file log.txt which contains the entirety of the output from the above command: log.txt.
I am totally confused by this problem, and have no idea what could be wrong. Given that I successfully analyzed zprint 1.2.7 with my local copy of cljdoc running (where I run the sever locally), and now cannot successfully analyze that same code, I'm at a loss as to what could be the problem. I had upgraded babashka along the way, but tried downgrading it to a previous version -- no change.
I've probably done something that is causing this, but I have absolutely no idea what it could be. Any help would be appreciated.
Thanks!