Clojurians Log v2

If anything in your project includes the dev namespace at dev time, dev/my-fn will be available, without any magic, without any tie to particular tools.

you can use :preloads to make sure its compiled and available to use

Thanks both! I'll give it a go 🙂

Now I'll just a have to think of a memorable (preferably short) two-segment ns name 🤓

Doesn't have to be two-segment. Although it's recommended, yeah.

Trying to discover, through my editor, the code, and properties of https://www.ag-grid.com/react-data-grid/getting-started/ and failing, is making me wonder if the challenge in discovery isn't somehow a feature for the Library mainters: E.g They want me to visit their docs/website, to idk, see adds or sign up for training classes, or buy a book. I feel 2/3rds of the reason AI is eating traditional software is because it's next to impossible to really communicate outside english, e.g 2/3rds of behavior is documented in english, and finding the code, and learning the important side effects, is 9/10ths of the effort, but next to impossible. I just give up everytime now and ask google search or AI.

> and failing But why? What are the pain points? > They want me to visit their docs/website, to idk, see adds or sign up for training classes, or buy a book. At the very least, they want to do that because reading someone else's code can be significantly harder than just reading the docs. Assuming the docs are reasonably well-written. > I just give up everytime now and ask google search or AI. Ask what exactly?

Thanks @p-himik I'll start with the goal. From my editor i can easily goto the definition of clojure.core/inc and browse the file. I can do it using LSP, or ciders xref function. I can quickly confirm that by "inc" we mean input + 1. nice. Meanwhile, in my project i have this: ["ag-grid-react" :refer [AgGridReact]] and AgGridReact, i can't seem to get any information, about anything. So to the question "ask what exactly" the answer is "any and all questions". "ag-grid-react" is declared in our package.json and that's used by figwheel (so maybe there is configuration there that enables or disables making code searchable?). To the best of my knowledge AgGridReact is a javascript Class. So i should be able to call js-keys on it?

(js-keys AgGridReact)
;; => #js[];; Lists static properties of the class

(.getOwnPropertyNames js/Object (.-prototype AgGridReact))
;; => #js["constructor" "registerApiListener" "componentWillUnmount" "render"]

(js-keys (.-propTypes AgGridReact))
;; => #js[]

(js/console.dir AgGridReact)

> i can't seem to get any information, about anything That's a limitation of the IDE, so not related to the library itself. Cursive also suffers from it, although there were some promises to make such navigation work, IIRC. I usually just manually go directly to node_modules and browse the code there. If it's minified, I download the original sources from wherever they're hosted and open them as a separate project. Regarding viewing the result of js/console.dir (BTW no need for dir, log also suffices; I pretty much always use just log), it seems to be an artifact of using cljs-devtools. If you view it as a plain JS object, I'd guess there's no recursion. > it's suggesting the issue is that the information (the type information) was stripped out of the code before it was downloaded (in my cause using figwheel). Kinda, I guess. If a package is TS, the type information is not available at run time - it's stripped during compilation. But some NPM libraries ship TS code, or they ship TS interfaces in addition to JS code that was compiled from TS or written manually. Figwheel has nothing to do with it. > my tools, and myself, don't know how to navigate TS Ah, well, just configure your IDE and the rest should be similar to e.g. Java. :) > The even deeper issue is the dwindling nature resources and rising tides, which i'll now contribute to by asking an LLM to answer the question i had about AgGridReact -_-. At least for older models, plain text queries were cheaper in terms of energy than a Google search. If you don't use dozens of agents, deep reasoning, and image/video generation - don't sweat it. Even with deep reasoning and dozens of agents - if they consume, say, 100 W*h of energy, but save you a few hours of work while your PC consumes, say, 200 W*h, it's a definite net positive in terms of environmental impact. But, of course, it's very hard to gauge at times whether something has saved you some time or has caused more problems...

Not programmatically, unless you connect to a running instance of your browser from within itself. But yeah, you can just inspect it in your browser's DevTools. Not sure about Node though, but there are probably some tools for it as well.

js/console.dir is occasionally helpful

(js-debugger) might help. I've always wondered if there was a way to trigger Firefox's "Store as Global Variable" from the REPL so you can capture a variable to play with later in the browser console - don't think there is.

"Store as global variable" is literally (set! js/window temp0 the-var). :) Just gotta be careful with overriding any existing temp... keys.

oh hah, thanks @p-himik!

Not typical. And long polling should not be an issue at all.

Thanks @p-himik. Interesting, I just tried again now and am not seeing the delay. I do seem to get occasional REPL blocking on execution if I have multiple Firefox tabs open to localhost:9000 (easy to do with the default :launch-browser true). Not sure whether that's related to the delay I was seeing. I haven't seen this behaviour with Chromium so far.

Well, it could be that multiple tabs with the same domain share the execution thread and one tab being busy means that the rest don't have enough time for their own computations. But such a behavior used to also exist in Chromium. Maybe something has changed, dunno.