Can you try deleting code until the error disappears, and try to get to a minimal reproducing case that way? Does it still happen if the protocol and record are in the same ns? Does it still happen if you remove the reset! and >!! forms?
Is that whole code within a custom macro? The name e# for the exception seems to suggest this is part of a syntax-quote? On 29 December 2017 at 01:13, Luc <lprefonta...@softaddicts.ca> wrote: > Hi, > > I am baffled. I switched a project from 1.8 to 1.9.0 upgrading also other > dependencies > (latest version fo core.async, ...) via lein ancient. > > As usual I ran an AOT pass to make sure I don't have anything fishy before > running the code. > > I got this from the AOT pass: > > java.lang.UnsupportedOperationException: Can't type hint a primitive local > > Oupse... I Reverted to 1.8 w/o reverting the dependency changes. it AOTed > w/o a glitch. > > I narrowed it at: > > (:ns ....) > (defprotocol GatewayJob > (start-job! [this] "Start the given job") > ...) > > (:ns ....) > (defrecord NoopJob [name job-controller-channel env job-state parameters > job-output] > impl/GatewayJob > (start-job! [this] > ... > (try > .... > (catch Exception e# > (reset! job-state :failed) (>!! job-controller-channel [this > :new-state :failed :error e#]) > (log/error (format "NoopJob job died unexpectedly !") e#) ))) <- > Here > > error is a macro which expands here to: > > (clojure.tools.logging/log* logger__458__auto__ :error nil > (clojure.core/print-str "NoopJob job died unexpectedly !")) > > The (try (catch...) compiles w/o problems outside of the protocol > implementation. It bombs a soon as it is > embedded in a protocol implementation. 3 instances in three different > namespaces same behavior and same > code pattern (try .. catch .. reset! >!! ... > > I have been toying with this for an hour but I need some new direction(s) > to eventually nail it. > I dived in the list of changes of 1.9 but my search didn't come up with > anything relevant yet. > > Anything changed in the defrecord macro expansion that could explain this ? > Something related to core.async ? (it works with 1.8 w/o reverting the > other dependencies however) > A malpractice in the code structure that was tolerated so far ? > > I looked at the macro expansion of the defrecord but did not find anything > wrong on the surface. > > Note that I did not yet attempt to run this project from source. That's > forthcoming but I would expect > it to crash at runtime.. > > Any idea is welcomed. > > Thank you, > Luc P. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
