This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (34)
- # boot (111)
- # cider (37)
- # clara (57)
- # cljsjs (1)
- # cljsrn (22)
- # clojure (156)
- # clojure-austin (2)
- # clojure-mke (7)
- # clojure-russia (9)
- # clojure-spec (221)
- # clojure-uk (47)
- # clojurescript (42)
- # code-reviews (4)
- # community-development (9)
- # core-async (3)
- # cursive (50)
- # datomic (81)
- # emacs (12)
- # events (5)
- # hoplon (1)
- # jobs (2)
- # lein-figwheel (4)
- # leiningen (1)
- # luminus (3)
- # mount (2)
- # off-topic (1)
- # om (94)
- # om-next (3)
- # onyx (33)
- # re-frame (23)
- # reagent (41)
- # remote-jobs (9)
- # rum (30)
- # slack-help (2)
- # specter (1)
- # untangled (20)
- # yada (17)
Although updating just that dependency gives me
clojure.lang.ExceptionInfo: No such var: dir/scan-dirs file: "system/boot.clj"
That error is probably because you're using an explicit dependency on an old
Needs this in your
boot show -p shows the conflict:
[✔] org.clojure/tools.namespace ✔ 0.3.0-alpha3 org.clojure/tools.namespace org.danielsz/system ✘ 0.2.11 reloaded.repl ✘ 0.2.10 ring org.clojure/test.generative
So you’d need to add
:exclusions to those dependencies so
system can bring in the right version.
(yeah, experience and good guesses led to adding the explicit tools.namespace dep)
boot show -p shows a lot of potential conflicts with that huge swath of dependencies you’re pulling in...
Some will be harmless but you may be surprised at some of the older versions that are “winning” in those conflicts...
As an example, add
:exclusions [commons-codec] on both
com.datomic/datomic-free so that
om “wins” with
(we ended up with global exclusions in our
build.boot for a number of common libraries — and then having explicit dependencies to pull in the correct version)
I was surprised you had so many old dependencies via Ring but then realized you’re using 1.5.1 and we’re on 1.6.0-beta7
I wouldn’t use any snapshots in production (hint, hint @danielsz 🙂 ) but I would pretty much always run the latest releases (including alphas, betas) unless they broke my system… but it depends how risk averse you are
I'm trying to build a small but professional system for a client with a large time window
We’re already using Ring 1.6.0-beta7 in production, and Clojure 1.9.0-alpha14, for example.
Are you planning to use any particular monitoring system in production for this application?
I ask because we use New Relic and it supports Jetty beautifully but doesn’t support http-kit very well (so we run DEV on http-kit and QA/production on Jetty at the moment, with the web server encapsulated in a Component so we can conditionally start / stop either, based on runtime configuration).
Yeah that's the purpose, so the state can monitor jail aprehensions and take decisions upon that
clojure has a lot of conflict, since it's the base of it all do I have to fix it all?
(set-env! :exclusions ['org.clojure/clojure ‘org.clojure/clojurescript])
build.bootthen only explicitly bring in the versions you need.
@seancorfield Next stable release for
system is imminent. I don't expect any changes. It's a matter of writing an announcement and explaining the changes.
danielsz: I’m mostly just teasing. I was surprised there wasn’t an alpha with that
Yup, they landed this afternoon. I’m on a one man mission to convince everyone to start using threads to reduce noise / chaos in channels! 😆
Hello, I've pushed my repo, now the error is another I think related to the system lib, since it doesn't have any channel I'll post here, the error is as follow I'm reproducing the same structure as the boot-system example
I can run
boot repl with no errors. What do I need to do to trigger the bug you're seeing?
diff --git a/src/om_learn/db.clj b/src/om_learn/db.clj index b331059..de48f7a 100644 --- a/src/om_learn/db.clj +++ b/src/om_learn/db.clj @@ -1,7 +1,6 @@ (ns om-learn.db - (:require [[system.core :refer [defsystem]] - (system.components - [datomic :refer [new-datomic-db)]) - [om-learn.server :refer [handler]] - [environ.core :refer [env]]) - + (:require [system.core :refer [defsystem]] + (system.components + [datomic :refer [new-datomic-db]]) + [om-learn.server :refer [handler]] + [environ.core :refer [env]]))
So, delete one
[ in line 2, and change
]]) on line 4, and add a closing
) on line 6.
wow surprised cider didn't caught that, sorry for bothering with such easy tasks, gotta have a better eye
NP. The error is misleading. I loaded each of the source files into Atom / ProtoREPL and that gave me the parse error directly on
db.clj and highlighted it for me.
I've found an issue related to clojure but I don't have a symbol name with digits
@pesterhazy I have tested that it works, but I'm not sure what to do with it as it is a breaking change, in sense that it will add a warning to many projects the currently work fine
hm I don't think it would be breaking in the sense of causing something to not work that worked before
adding the warning is kind of the point, as many don't realize they have a dangerous configuration
"dangerous" in the sense that just adding a random JS file has a significant probablity to cause random exceptions
I know we only caught this in production after a few days (following an innocuous change)
hey folks, What is the right way to catch the control-c event ( or handling POSIX signals ) ?
Alas, I don’t see anything wrong offhand, but here’s one of mine that does the job: https://gist.github.com/dball/28fae154b7d8db0e6d5f763a8738f551
Hi folks. FYI https://github.com/migae/boot-gae has been updated. It’s a little simpler, and it handles service-based applications rather nicely, I think, with REPL-like support for service components. See also https://github.com/migae/boot-gae-examples, which demonstrate both servlet-based and service-based apps from thje same codebase. I think it’s about ready for an official release, but I would greatly appreciate it if anybody would give the examples a try and let me know a) if it works and b) if the documentation is satisfactory. Long Live Boot!!!
that should really nicely solve the issues my junit test task has around reloading Java classes...