Austin in the wrong profile causes AOT crash #23
Comments
|
Maybe I missed something scrolling through the output, but how is Austin affecting AOT? Not to say I doubt that Austin is to blame, I just can't think of a way, and I don't see a mention of it in the stack, etc. |
|
I ran into the same issue in the early stages of a ring/compojure/http-kit app. I added austin and everything was working fine, but then I ran a I didn't realize that it had anything to do with austin until I asked for help in IRC, so I began selectively removing bits and pieces to see where the culprit was, and I narrowed it down to any calls involving middleware. Removing austin as a plugin fixed the issue. |
|
I should also note that I had austin in my :dev profile. |
|
Oh, I'll bet there's a version mismatch going on. What revs of ClojureScript, lein-cljsbuild, and austin are you using? |
|
austin: 0.1.3 |
|
Same issue here. Didn't realize this was Austin's doing. |
|
same here, with 1.0.0 lein-cljsbuild and cljs 2016. austin 0.1.3. Excluding org.clojurescript/clojurescript doesn't help either. |
|
My problem goes away if I run my uberjar with an explicit main class, instead of java -cp myjar.jar clojure.main -m paddleguru.serverThat was my mistake, as doing it this way double-compiles, causing issues with protocols. My guess is that Austin includes some dep, maybe piggieback, that depends on cljs and has a |
|
I managed to get around this by moving the plugin to dev, then using these two macros to add my dev calls to my code shared with production: (defn try-require [sym]
(try (require sym)
(catch Throwable _
(println "Namespace not available in current mode!" sym))))
(defmacro maybe-resolve [ns method]
`(when-let [n# (find-ns (quote ~ns))]
(when-let [m# (ns-resolve n# (quote ~method))]
@m#))) |
|
I'm having the same issue in this project: https://github.com/bellkev/dacom/tree/2a352a4da42993c046bc018a5dbf1b1080e959d4 Moving the plugin to the dev profile was a sufficient workaround for me. |
|
+1 |
|
@LiFlash yup, that does make sense. I have it in my uberjar profile. |
|
@sritchie Thanks for the info. Hopefully I will understand what it is about (besides not delivering the source code), soon ;) |
|
I have a sneaking suspicion this is related to #37… Open to any and all ideas as to what's going on. |
|
Moving it to [cemerick.austin.repls :refer [browser-connected-repl-js]]but since austin is only in |
|
I do this for Weasel (same pattern worked for Austin): (ns paddleguru.repl
"Helpers for interacting with Austin: https://github.com/cemerick/austin"
(:require [paddleguru.util :as u]))
(u/try-require 'cemerick.piggieback)
(u/try-require 'weasel.repl.websocket)
;; Use these to get the REPL running locally, connected to our live
;; server instance. For this to work you'll need to have started the
;; app from the repl itself.
(defn start! []
(when-let [cljs-repl (u/maybe-resolve cemerick.piggieback cljs-repl)]
(when-let [repl-env (u/maybe-resolve weasel.repl.websocket repl-env)]
(cljs-repl :repl-env (repl-env)))))Here are (s/defn try-require :- nil
[sym :- Symbol]
(try (require sym)
(catch Throwable _
(println "Namespace not available in current mode!" sym))))
(defmacro maybe-resolve [ns method]
`(when-let [n# (find-ns (quote ~ns))]
(when-let [m# (ns-resolve n# (quote ~method))]
@m#)))That way I can have code that injects the repl snippet that works in dev mode, but just returns |
|
Complete speculation, but this might be related to: http://dev.clojure.org/jira/browse/CLJ-1544 I see CLJ-1544 when a namespace containing a protocol manages to get require'd before AOT starts. |
|
I have investigated http://dev.clojure.org/jira/browse/CLJ-1544 today and I can confirm this is the root cause for this ticket. |
mea culpa for leaving
[com.cemerick/austin "0.1.1"]in the general plugins section of my project.clj, but it caused some pretty difficult to track down problems with AOT (specifically with the clojure.tools.reader.edn reader-types class). Not sure how to fix this more generally - austin shouldn't be involved in production cljs, since it wouldn't work anyway, but it would be nice if it errored-out or warned when used in production profiles.Here is the example output that I had when tracking down the issue:
As a question though, how do you go about disabling austin when compiling for production? Do you simple comment-out the line in the
:requirens-form?The text was updated successfully, but these errors were encountered: