Fork me on GitHub
#clojure-dev
<
2021-09-29
>
Marc O'Morain11:09:12

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?

Alex Miller (Clojure team)12:09:35

it's got 13 years of patches applied, it's not consistent

Alex Miller (Clojure team)12:09:56

but I usually use 4-space tabs when viewing it

Marc O'Morain12:09:54

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?

Alex Miller (Clojure team)12:09:02

if you're asking whether you'd want to purpose it for this, I'd say no

Marc O'Morain12:09:35

I’ve done a quick prototype here, to see how feasible this would be: https://ask.clojure.org/index.php/ask?follow=11117&amp;cat=4

Alex Miller (Clojure team)12:09:31

I won't have time to look at anything till next week

Marc O'Morain12:09:14

No problem at all.

mpenet12:09:16

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

hiredman15:09:07

My immediate guess is concurrent code loading, maybe try putting a lock around the requiring resolve

hiredman15:09:40

Oh whoops, right serialized require

hiredman15:09:52

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

mpenet16:09:58

I didn't find any separate require so far

mpenet16:09:11

That's the first thing I thought of

mpenet16:09:49

I think I might be missing something obvious. I ll check again tomorrow with a clear head (not in front of the computer now)

mpenet12:09:34

I cannot reproduce it either, it just pops in our sentry sometimes

mpenet12:09:16

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

mpenet12:09:54

the required ns is not used anywhere else either (so no "lone" require call somewhere else that would cause some concurrency issue)

mpenet12:09:23

anyway, if that rings a bell I am all hears

ghadi13:09:00

are you loading your application via Java @mpenet? (either through clojure.java.api.Clojure or otherwise)

mpenet13:09:19

it's an uberjar'ed service

mpenet13:09:29

pure clojure

ghadi13:09:52

starting clojure.main or a gen class?

mpenet13:09:35

the ns where the fn resides is not used/loaded anywhere else, as far as I can see in the sources

ghadi13:09:37

(I'm trying to rule out something grabbing a var before Clojure runtime initializes)

mpenet13:09:22

actually I think it breaks after it (the service) has been running for a while

mpenet13:09:30

which makes it even weirder

mpenet13:09:43

anyway I need to do more digging

cfleming17:09:37

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.