This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-14
Channels
- # adventofcode (107)
- # aleph (1)
- # announcements (8)
- # beginners (57)
- # boot (3)
- # braveandtrue (18)
- # calva (374)
- # cider (6)
- # cljdoc (8)
- # cljs-dev (140)
- # clojure (199)
- # clojure-berlin (5)
- # clojure-europe (3)
- # clojure-finland (1)
- # clojure-hamburg (4)
- # clojure-italy (17)
- # clojure-nl (16)
- # clojure-spec (2)
- # clojure-uk (70)
- # clojurescript (29)
- # component (2)
- # cursive (10)
- # datomic (44)
- # docker (1)
- # figwheel (3)
- # fulcro (13)
- # immutant (2)
- # juxt (5)
- # leiningen (53)
- # nrepl (3)
- # off-topic (7)
- # pedestal (3)
- # re-frame (7)
- # ring (3)
- # ring-swagger (5)
- # rum (5)
- # shadow-cljs (14)
- # spacemacs (6)
- # specter (12)
- # tools-deps (11)
- # unrepl (11)
- # vim (7)
hey guys, i am trying to generate the war
file of my compojure-api project but it keep generating a jar
, help!!!
@UEA9PJ9FE what did you try, what's your project configuration? How do you call it?
hey @U06BE1L6T, i added main
to my project.clj
setted a name for uberwar
, then ran lein ring uberwar
.
I have lein check
that started to fail on travis as the satisfies?
call on on a protocol returns false
for no good reason. Works still locally and worked before. When it started failing, the ns checking order changed on travis. Any ideas what and why this happens?
order in the successful one:
Compiling namespace muuntaja.core
Compiling namespace muuntaja.format.core ;; the defined protocol
Compiling namespace muuntaja.format.edn
Compiling namespace muuntaja.format.json
Compiling namespace muuntaja.format.transit
Compiling namespace muuntaja.interceptor
Compiling namespace muuntaja.middleware
Compiling namespace muuntaja.parse
Compiling namespace muuntaja.protocols
Compiling namespace muuntaja.util
Compiling namespace muuntaja.format.cheshire
Compiling namespace muuntaja.format.yaml
order in the failing one:
Compiling namespace muuntaja.format.msgpack
Compiling namespace muuntaja.interceptor
Compiling namespace muuntaja.middleware
Compiling namespace muuntaja.format.edn
Compiling namespace muuntaja.format.core ;; the defined protocol
Compiling namespace muuntaja.format.json
Compiling namespace muuntaja.format.transit
Compiling namespace muuntaja.parse
Compiling namespace muuntaja.core ;; fails here
@U055NJ5CC what is your question? Why satisfies? is sometimes false or why the order is changing sometimess?
the true/false non-determinism is looking like it should be due to the order changing around
so if that side-effect doesn’t happen before the satifies? call some of the time, those times it’ll be false
it is likely something to do with the order of loading the protocol and whatever is supposed to satisfy the protocol
I think so. I would think lein check
should run the checks in order that things get loaded in right order?
I forget, but I believe check more or less traverses the namespaces at random (not really random, but not a well defined order) and basically does a require :reload on them
I am looking at it, but having a little trouble navigating the project because it is new to me and I haven't used whatever module lein plugin this uses
usually for something like this what I find is 1. a missing require that was covered up some how 2. using the interface instead of the protocol 3. aot weirdness
actually, you might have another issue as well, check just loads the code (it doesn't invoke tests, etc)
ok, thanks for checking it out. Could be the project layout, the :dev
requires all the module sources.
so while I don't know this library or what it does, it is very surprising to me that you are running something at code load time
the only ordering you know will happen is the dep order of :require
s, but still can have different entry points
so if you capture the value of the var, you won't get updates to the protocol (if it is extended to new types, etc)
so instead of doing (ensure! Decoder) you should do something like (ensure! #'Decoder) and inside the fn returned by ensure! deref the var as needed
fixing that will likely fix https://github.com/metosin/muuntaja/issues/90
the smoking gun is actually in the travis ci output, the captured value of the protocol var is in the map in the error message under the :protocol
key
thanks! Will try that when at computer. Is there an explanation about protocols mutating vars somewhere? Would like to understand how they work.
I don't know of any, but a rule of thumb is, if you are refering to a protocol by a name other than the one created via defprotocol you will likely run into this
@U0NCTKEV8 coudn’t make it work. will post a minimal failing case into #clojure