This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (45)
- # asami (30)
- # babashka (96)
- # beginners (24)
- # calva (43)
- # chlorine-clover (3)
- # cider (10)
- # clj-kondo (45)
- # clj-new (4)
- # cljdoc (10)
- # cljs-dev (2)
- # clojars (5)
- # clojure (139)
- # clojure-australia (5)
- # clojure-europe (53)
- # clojure-filipino (1)
- # clojure-germany (27)
- # clojure-nl (4)
- # clojure-provo (7)
- # clojure-serbia (6)
- # clojure-spain (1)
- # clojure-uk (8)
- # clojuredesign-podcast (8)
- # clojurescript (76)
- # code-reviews (6)
- # conjure (4)
- # core-async (1)
- # crux (28)
- # cursive (72)
- # data-oriented-programming (2)
- # data-science (3)
- # depstar (7)
- # docker (16)
- # duct (7)
- # events (1)
- # fulcro (13)
- # girouette (1)
- # graphql (4)
- # honeysql (11)
- # jobs (2)
- # joker (1)
- # kaocha (4)
- # leiningen (5)
- # malli (11)
- # off-topic (14)
- # other-languages (1)
- # pedestal (4)
- # practicalli (1)
- # re-frame (5)
- # reagent (3)
- # releases (2)
- # remote-jobs (7)
- # shadow-cljs (12)
- # sql (24)
- # startup-in-a-month (2)
- # tools-deps (99)
- # vim (8)
- # vscode (1)
So this was what you helped me with, yesterday, @dpsutton and @seancorfield https://github.com/PEZ/taplet I notice that the tests are not as predictable as I would expect them to be. It sometimes seem like they write over each other’s atoms, but since they are locals that really can’t be happening. Anyway, I don’t understand why the tests get brittle. Not planning to put this in CI, though, so it is OK for now. Anyway, I have a bunch of questions about macros now, so will probably return here. Thanks again for the super duper support!
Hello. #vscode channel looks like forgotten, so sorry for asking here - is there any usable Clojure code formatter for VSCode?
Thanks, I used it several years before it becames unusable due to unswitchible lsp integration. Now I installed Clover, clj-condo linter and only one thing I need is formatter.
Just to be curious, what issues you had with Calva LSP(clojure-lsp)? Maybe we can improve that
Now I’m wondering how I can load these files and symbols from the Java project into my clojure namespace to make it accessible to the compiler
@dev-hartmann a convention in some clojure projects is to have a directory
classes where you emit these classes and then put
classes in your
:paths in deps.edn. For lein this directory is called
target and it is on the classpath by default
Thx @borkdude I guess I can get maven to export the classes from the other project and cp them into a classes folder in my clojure project
:local/root + adding
deps.edn in that project might also work, if the path is not within the project
@dev-hartmann if the other project has a
pom.xml and the classes are on the classpath of that
pom.xml, then you can use
:local/root to add that project
I can import the complete project as a dependency but specifiying it is local 👌:skin-tone-4:
what would be a good way to block a thread until a channel (or atom) holds a specific value?
(defn when-is [a v] (let [k (Object.) p (promise)] (add-watch a (fn [a k ov nv] (when (= nv v) (deliver p true) (remove-watch a k)))) (when (= @a v) (deliver p true) (remove-watch a k)) @p)) ;; the order of args to the watch fn is likely wrong
regarding the add-watch argument order, I've found
kron to be helpful as a mnemonic (Key/Ref/Old/New)
sure, I was thinking more in terms of how the Clojure compiler/runtime works, not so much the API layer, but I don’t know nearly enough about how Clojure is implemented to know whether something like, say, pattern matching of records, can provide any value (ex: like for optimizing
cond or something)
I do not care about the language level stuff in JDK 16, but the VM level stuff is absolutely massive
high-level SIMD API (Vector API, incubating) call C functions directly without writing a lick of JNI (Foreign Linker API, incubating)
> call C functions directly without writing a lick of JNI does this bring a Python-like FFI for C libs for Clojure a bit closer?
niiice :) hope it works with GraalVM as well, can add it to bb and have more lib reach :)
GraalVM will update to 16 /17 eventually, but are there any technical reasons it shouldn't work?
The latest inside java podcast https://inside.java/podcast/ gave a nice, easy to understand overview of the new stuff in java 16
TIL re: Java 16 — public constructors for the primitive wrapper classes (`Long`,
Integer, etc) have been deprecated since Java 9 (searches all his code, finds no such uses 😅 ).
Not yet, but in Java 16 you’ll get warnings on their usage. And they will go away eventually. I’d just totally missed they’d been deprecated for so long!
oh i didn't realize 16 started emitting warnings about them. i knew they were deprecated for a while
the clojure reflector already checks for "canAccess", is this something it could do too? or too much perf overhead / info not available in the JVM?
what I've found in the past is that canAccess will only give feedback when it's set to "deny", so it probably won't help until they actually turn it off
I don't think we want to be in the business of checking for specific invocations inside the reflector
I agree about not adding specifics. Was just wondering if https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Constructor.html had a field "deprecated" or something, but it hasn't.
https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/Boolean.html#%3Cinit%3E(boolean) - you can see that the info is there and I think that's retrievable
the annotation has to be marked to be marked for runtime retention but that one should be
so, I'll change my answer - yes, it's possible to programmatically detect this in the reflector :)
yeah, that would need assessment. I would not be opposed to an ask.clojure question about this, might generally be a useful thing, at least as an option
seems like a semi-obvious idea that has been available since Java 5, so basically forever in Clojure release lifetime
Oh does kondo not warn on this? Cider nrepl has done this for a while and it’s quite nice. I’m doing a month without nrepl and didn’t look into this yet
currently warns on deprecated vars. I just made an issue for deprecated methods/constructors, but it doesn't do that yet
I didn't expect that
(binding [*read-eval* false] (load "some/ns")) would still execute a contained
I guess there's no built-in way to forbid read-eval literals in clojure namespaces?
user=> (binding [*read-eval* false] (read-string "#=(println :foo)")) Execution error at user/eval138 (REPL:1). EvalReader not allowed when *read-eval* is false. user=> (binding [*read-eval* false] (load-string "#=(println :foo)")) :foo nil
if you're loading code, does it matter if there are the
#= forms? it's executing everything right? you're trusting the source
this slightly pre-dates my involvement with Clojure core, but my recollection is that read-eval is there to prevent read eval when reading untrusted data with read. Code on your classpath (loaded by load) is presumably there because you put it there and it is considered to be trusted and thus outside the scope of read-eval
@borkdude yeah precisely, it's that difference that I found surprising. TIL about
yeah that reasoning makes sense, in the end one is also evaling a string when doing
But the difference might be considered quirky.
I ended up using tools.reader. It offers its own
*read-eval* var; if binding it to false while content some contents one will get an exception, as I was seeking
you're right, it's not an essential part. In my project tools.reader is used for all reading needs though
[clojure.core/*read-eval* false] in combination with tools.reader does not result in errors being thrown, but in nil values being read
#=() syntax, I've seen it in production projects and as I saw it, it wasn't either a good thing or something without viable alternatives
This is easier with clj-kondo or let's say, just rewrite-clj for example. Grasp assumes that your code already has been parsed correctly
Similar to how bb throws:
$ bb -e '#=(+ 1 2 3)' ----- Context ------------------------------------------------------------------ 1: #=(+ 1 2 3) ^--- Read-eval not allowed. Use the `:read-eval` option
You can also parse all your code with edamame (which is one level below grasp / sci)
and so threading last into a private function call at the repl is quite surprising at first.
(->> foo #'ns/private-fn) yields
Hi all, I am having a strange issue with spec instrumentation that throws where it should not...
What is peculiar is that the instrumentation exception show this
:via (notice the repetition):
[::report/report-identifiers ::report/report-identifiers ::report/image-descriptors ::report/image-descriptor ::report/image-id]
I am having trouble even debugging it...cause the registry seems to return the above spec definition but the instrumentation check then fails...do you folks have any hint?
(s/def ::report-identifiers (s/keys :req [::id ::version-id]))
it seems like the instrumentation check my fully qualified key even if not in