This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-29
Channels
- # aws (8)
- # babashka (45)
- # beginners (83)
- # cider (23)
- # clj-on-windows (4)
- # cljdoc (23)
- # clojars (6)
- # clojure (68)
- # clojure-dev (33)
- # clojure-europe (75)
- # clojure-nl (1)
- # clojure-uk (4)
- # clojurescript (14)
- # conjure (6)
- # data-science (15)
- # datascript (7)
- # datomic (47)
- # docker (15)
- # events (1)
- # fulcro (4)
- # graphql (3)
- # jobs (4)
- # lsp (14)
- # nginx (2)
- # nrepl (2)
- # off-topic (41)
- # pathom (18)
- # pedestal (1)
- # polylith (72)
- # reitit (8)
- # reveal (1)
- # shadow-cljs (48)
- # tools-build (11)
- # tools-deps (24)
- # xtdb (8)
I’m having problems visually parsing src/jvm/clojure/lang/Compiler.java
Is the file intended to be indented with 4 or 8 space tabs?
It’s a genuine question – I’m having a go at writing a patch for https://ask.clojure.org/index.php/11114/emit-warning-when-calling-a-deprecated-java-function
it's got 13 years of patches applied, it's not consistent
but I usually use 4-space tabs when viewing it
Thanks Alex – one more question – all compiler warnings seem to be conditional based off whether *warn-on-reflection*
is true.
Is it fair to say that *warn-on-reflection*
has grown to become an indicator that the user wants to receive compiler warnings in general?
if you're asking whether you'd want to purpose it for this, I'd say no
I’ve done a quick prototype here, to see how feasible this would be: https://ask.clojure.org/index.php/ask?follow=11117&cat=4
I won't have time to look at anything till next week
No problem at all.
we have this weird bug: a piece of code that calls requiring-resolve on some symbol, pointing to a fn in another ns (nothing exotic). Calls to that fn fail initially and then work fine subsequently. I am a bit baffled. We get a Attempting to call unbound fn: #'foo.bar/baz
My immediate guess is concurrent code loading, maybe try putting a lock around the requiring resolve
But serialized-require is only called for requiring-resolve, if you have normal code loading going on at the same time, you can still race
I think I might be missing something obvious. I ll check again tomorrow with a clear head (not in front of the computer now)
I know that requiring resolve relies on serialized-require so in theory that should be safe, but I am wondering if there's not a bug somewhere at this level eventually
the required ns is not used anywhere else either (so no "lone" require
call somewhere else that would cause some concurrency issue)
are you loading your application via Java @mpenet? (either through clojure.java.api.Clojure or otherwise)
the ns where the fn resides is not used/loaded anywhere else, as far as I can see in the sources
I actually see something like that in Cursive too, which I’ve been meaning to investigate. I call into Clojure from Java/Kotlin a lot, and I have a delay() function which creates an implementation of IFn called DelayedFn. It delegates all its calls like this:
public Object invoke() {
return getDelegate().invoke();
}
getDelegate()
uses double checked locking like this:
private IFn getDelegate() {
// See
IFn result = delegate;
if (result == null) {
synchronized (this) {
result = delegate;
if (result == null) {
if (!"clojure.core".equals(namespace)) {
REQUIRE.invoke(asSym(namespace));
}
delegate = var(namespace, name);
result = delegate;
}
}
}
return result;
}
Here delegate
is volatile. This mostly works but every so often I get an error reported in my tracker that a var called in this way is unbound. However I’m not using serialized-require
since this predates it (and I also just learned about it here), so perhaps that will be my fix.