noob question/clarification: this isn't spec-specific, but in the docs for spec, there's a section on spec names that says the following: > In this guide we will often use auto-resolved keywords like ::date My question is: does "auto-resolved" mean that, if say I have a ::date keyword declared inside the namespace my-app.foo it's the same as if I had declared the keyword like :my-app.foo/date?

actually I just answered my own question in the repl lol

client:cljs.user=> (= ::foo :cljs.user/foo)
true

I am wondering if this is an error, or me misreading things (and I am betting on the latter)! The Clojure docs, http://clojure-doc.org/articles/language/concurrency_and_parallelism.html#futures, state “Clojure futures are evaluated in a fixed size thread pool that is also used by agents (updated via clojure.core/send). However, when I look at the source of future, it uses future-call, which submits the future to clojure.lang.Agent/soloExecutor. That appears to be the Executor used by send-off, which is an unbounded cached thread pool. Should the docs be fixed, or am I reading this wrong?

Those are community docs, and they are wrong

Your reading of the code is correct

Yup, I noticed after posting the way it said “Community docs.” I will research how to submit a correction. Thanks, Alex! How do you have time to answer all these questions? 🙂

(And, BTW, the actual implementation is the way I fervently wanted it to work.)

There are actually 3 Alex Millers, doing tag-team work.

@deep-symmetry Not sure I follow what you mean by "an unbounded, cached thread pool" in that PR?

Which part?

The "cached" part.

There is no upper bound on the number of threads created, but when the future finished, the thread is returned to the pool for reuse, for a timeout period, after which point it is terminated.

*finishes, that is.

That doesn't seem to fit with the word "cached" to me...

I believe that is the terminology used in the Executors package documentation. Let me check…

it's also the name of it apparently: volatile public static ExecutorService soloExecutor = Executors.newCachedThreadPool(

Yes. https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool(java.util.concurrent.ThreadFactory)

Interesting. OK, fair enough 🙂 Just wasn't what I expected given how "cached" is used in Clojure function docstrings.

I'll approve the PR 🙂

Thank you! I could also spell out what it means in more depth if you think that would be helpful.

Merged. Not sure how quickly it'll get published. Last I checked, the guides were still being manually published. I'll try to remember to check tomorrow and if it isn't updated, I should be able to kick off a manual publish operation.

(I'd forgotten I had permission to do all of that until your PR turned up in my inbox!)

There’s no hurry, I’m just hoping to help avoid future confusion. Oops, I truly did not intend that pun, although now I wish I had.

@andy.fingerhut @jaihindhreddy Thanks both, found it: > So like all design things, this is just: what was wrong? Two things were combined that should not have been combined. And how do you fix it? You take them apart. The rest of this -- this is all it is. The whole thing is this. You got a dictionary, and the idea of taking things apart, and you are done.

It was a joke, but there's a lot of truth to it.

I found a hack to redefine a clojure.core macro (for all future uses). I'm wondering if there are "better" ways of doing this: https://stackoverflow.com/questions/53871680/how-to-extend-and-redefine-a-clojure-macro

user=> (intern 'clojure.core '^:macro defn (let [defn @#'defn] (fn [&form &env & args] (println "wrap") (apply defn &form &env args))))
#'clojure.core/defn
user=> (defn a [b c] c)
wrap
#'user/a

it's disgusting, don't ever use it

but it's a marginally "better" way of doing it than that response's

Cool, thanks! I'll try that too

I'm trying to do some code analysis and adding dynamic checks to an older code base. So far I think this allows me to do that without breaking code (tests still pass)

depending on what you're trying to do, you could consider using https://github.com/clojure/tools.analyzer.jvm instead and doing the dynamic checks in the extensible macroexpander instead of adding them inline in redefined macros

it could be too big a hammer for what you need though

So one idea is too build a dependency graph of code that is calling code. I have a start by rewriting the function body. I wouldn't know how I could do that in clean way with tools.analyzer.jvm

The other idea is to add clojure.spec validation to the functions by reading the destructuring and using that as an indication of the expected structure of the arguments. I guess this could be done in a cleaner way with tools.analyzer.jvm

for the dependency graph I have a small example here https://gist.github.com/Bronsa/28720fbc280d661f91d7#file-gistfile1-clj-L15 (beware it's a non complete PoC)

Ah that's pretty cool to see!

it doesn't resolve transitive deps, but the idea would be to traverse the namespaces, building non-transitive sets for each function/macro, and then resolve the transitive deps of a form using that db

anyway, mocking/stubbing is probably easier, just thought I'd let you know about t.a. in case you weren't aware

yeah, thanks for showing me!

I have something working with macro redefining and a binding trick:

wrap-body (fn [body]
                    (if (or (recur-without-loop? body)
                            (recursion? fn-name body))
                      body
                      (list (list `register-call! `*parent-fn* current-fn-symbol)
                            (apply list `binding [`*parent-fn* current-fn-symbol]
                                   body)))

I had to add some exceptions for recursion where the binding approach fails

I hope to use this dependency graph to build a smarter test runner

I just made this public as a library FWIW https://github.com/Bronsa/tools.analyzer.jvm.deps

Finally https://twitter.com/stuarthalloway/status/1076028752218546176?s=09

it's been that way for a few years ;)

2+ yrs

maybe 3 years even

yeah, Jan 2016

The trick isn't in the wanting and welcoming the docs -- the trick is finding someone willing to go through the arduous process of researching, writing, re-writing after review ... 🙂

as it always has been…

Ugh! Don't get me started! I got so much grief about the java.jdbc docs being in the repo and therefore requiring a signed CA and JIRA patches to submit changes to them! I moved them to http://clojure-docs.org so everyone could contribute with just a pull request and -- with one notable example (and much gratitude to them!) -- crickets. Not one person who complained about the docs contrib process for java.jdbc submitted anything after I put them up on GitHub for the community to contribute. Grrr!!!

^ @ag 😠 🙂

(so the docs still mostly suck because I'm terrible at documentation!)

@seancorfield for what it's worth, I think your docs are great

I do wonder if some of this is about knowing what others think need writing.

When I'm on the http://clojure-docs.org, if I'm confused, where do I say that? Do I feel welcome to create an issue saying something confused me? I have no idea, I'm not trying to imply anything. I wonder how other communities approach this I

I find it odd that people would rather not do anything than raise issues

if something confuses you surely letting the authors & anybody who's watching they space know has a better chance to be useful than just staying confused and not telling anybody? :)

I worry that something I'm unaware of is blocking people from speaking up

most people just don’t want to spend the time raising issues

e.g. beginners who are most confused, probably just get tired and move on

it’s also hard to know the difference between “the docs are confusing” and “I just don’t know enough yet.”

http://clojure-docs.org is a dead end for me...did you mean http://clojuredocs.org?

http://clojure-doc.org and http://clojuredocs.org are both things, but not http://clojure-docs.org

both unofficial community-driven things, with mostly accurate stuff, but occasionally some erroneous info.

Has there been any movement to push towards one? Would that be preferred to having several doc sites with partially up-to-date and accurate info?

If you are presuming that having only one would make that one more accurate, I doubt that to be the case. http://clojuredocs.org are mostly examples of existing functions and macros, editable within a minute of creating a free account.

http://clojure-doc.org requires PRs, and I haven't gone through the process myself, but it can be very quick.

The limiting factor, in my opinion, to eliminating the very few inaccuracies is the right combination of knowledge, time, and will all wrapped up in the same head.

That’s a fair counter-point. Plus it appears http://clojure-doc.org is more focused on guides than docs for each function.

People with that combination of knowledge, time, and will seem to write books about Clojure instead 🙂

many thanks to you Andy for being the exception in the middle :)

Me? I'm crazy. 🙂

But you are welcome to the products of that insanity 🙂

Does anyone else find themselves reaching for http://clojuredocs.org most of the time? I find locating the function, reading an example or two, reading the docstring, then peeking at the source when needed has exponentially increased my absorption rate. Interestingly, I think Clojure is the first language I’ve encountered where the source can sometimes be more concise and helpful than the docs.

http://clojuredocs.org was really useful to me when I started learning the language (and I still use it sometimes), then I became more comfortable reading source and interpreting docstrings

I generally use http://conj.io because it includes the source with the examples and docstring

Posted weekly journal: http://insideclojure.org/2018/12/21/journal/

@jayzawrotny My workflow is to hit ctl-, d in Atom to see documentation (docstrings) inline in my editor (and also printed to my REPL window). And if I need deeper understanding, ctl-, c to view the source code in the REPL.

Occasionally, that's not enough and I'll just go to Bing and see what turns up on various people's blogs and mailing lists.

But between auto-complete in my editor and popping up the docstrings, that gets at most of what I need. find-doc and apropos are also very useful some times, when I'm not sure of exactly which function I want but I have a few key words in mind.

there's an emacs package to get doc strings in auto complete, and then i really love C-c C-d C-r for Cider Doc Grimoire which loads and formats the results from http://conj.io in an emacs buffer for me.

I usually just consult my hard copy of the Clojure source

in vim-fireplace you can hit [ C-d when over a function to be taken to the source, and K to get arg list + docstring 🙂 I find myself using this often, and only really going to the web when I want examples

I've added a http://conj.io integration to replant.vim, which means you can find examples for functions and run them as needed.

Although, I haven't documented that, so more fool me

Is this behavior expected?

cur
=> #{[:alert.type/integration-metric-auth-failure #uuid"e3f0ca53-594d-4903-bade-c3d4942dc6c6"]}
trig
=> #{[:alert.type/integration-metric-auth-failure #uuid"e3f0ca53-594d-4903-bade-c3d4942dc6c6"]}
(sets/difference cur trig)
ClassCastException java.util.HashSet cannot be cast to clojure.lang.IPersistentSet  clojure.core/disj (core.clj:1517)
(type cur)
=> java.util.HashSet
(type trig)
=> clojure.lang.PersistentHashSet

Yeah; you can’t disj from a regular Java HashSet (which is what difference does).

there are some language-specific tools for easing AWS cloudformation woes such as stacker (python), can anyone recommend something similar for clojure? CF is great for declarative data = infrastructure, but is quite bad at rollbacks, crossing dependencies, isolation, and that’s where stacker excels. but i don’t want to deal with python and an entire other ecosystem if it’s avoidable