This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-12
Channels
- # announcements (2)
- # beginners (36)
- # boot (6)
- # calva (2)
- # cider (18)
- # clj-kondo (1)
- # cljdoc (2)
- # cljs-dev (2)
- # clojure (130)
- # clojure-boston (1)
- # clojure-brasil (3)
- # clojure-czech (1)
- # clojure-europe (11)
- # clojure-italy (4)
- # clojure-losangeles (37)
- # clojure-nl (9)
- # clojure-seattle (2)
- # clojure-sweden (8)
- # clojure-uk (23)
- # clojurescript (13)
- # core-async (21)
- # cursive (13)
- # data-science (6)
- # datomic (12)
- # emacs (36)
- # figwheel-main (9)
- # fulcro (76)
- # juxt (2)
- # keechma (18)
- # leiningen (4)
- # off-topic (13)
- # pedestal (37)
- # re-frame (21)
- # reitit (2)
- # shadow-cljs (78)
- # spacemacs (23)
- # sql (13)
- # tools-deps (25)
- # uncomplicate (4)
- # unrepl (1)
- # vim (27)
@ghadi We talked on Tuesday (https://clojurians.slack.com/archives/C6QH853H8/p1562697498052500) about a tool that would "localize" (i.e. git/url -> local/root) certain dependencies before starting a REPL (or some other task). This would solve the problem of having a single project that depends on lots of internal libraries that often need to be developed in parallel with the project you are working on. You said "monorepo is a big hammer" and to take a "`read` => update
=> spit
" approach. The general approach makes sense but there are a few issues I immediately ran into while trying to work on this tool. I'm curious how you solved these for your company (it sounded like you guys have a tool that does this too).
When you "localize" dep libraries, how do you ensure that the library at a give local/root path is up to date with VCS? Often my local libraries are not up to date with the version on master. You could run a git
check before localizing and warn the user that the code at a given local/root is not up to date. Similarly, should you ensure your localized dep libraries are all on the same branch? I could easily see a situation where the local/root of a lib is on a different branch (maybe you started some work there and didn't switch back to master) than the other libs or the service itself that you are working on.
Both of those issues could easily cause strange behavior to occur which could be costly when debugging because you didn't have know the lib was not up to date or on the wrong branch. Having a monorepo would solve both of these problems (it introduces another set of problems though).
I keep seeing OOMs from JGIT - is there a different way to set the memory for the tools deps itself?
One way is to create an alias in a deps.edn file e.g. deep merge this into deps.edn map: {:aliases {:bigmem {:jvm-opts ["-Xms4g" "-Xmx8g"]}}}
. Then run clojure -A:bigmem
@andy.fingerhut so are you saying what I'm trying above won't work?
Oh, no, I believe it will work. I was responding more to the question I thought you were asking about a way to have settings for this.
And I probably misunderstood which JVM you wanted those options to go to, now that I read your question again.
@alexmiller it looks like clojure
has a hardcoded memory setting of -Xmx256m
??
Yeah, that is what I see in my /usr/local/bin/clojure shell script, too.
It’s hard coded for the process that builds the classpath
This is the first report I’ve seen of an issue with that but happy to mod
Curious what it’s doing when it fails. Maybe a git version compare?
@alexmiller PMed the output