This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-30
Channels
- # aws (5)
- # aws-lambda (2)
- # beginners (29)
- # boot (5)
- # cider (3)
- # cljs-dev (3)
- # cljsjs (2)
- # clojure (112)
- # clojure-austin (1)
- # clojure-brasil (2)
- # clojure-italy (9)
- # clojure-nl (2)
- # clojure-russia (5)
- # clojure-spec (49)
- # clojure-uk (41)
- # clojurescript (157)
- # core-logic (5)
- # crypto (1)
- # cursive (12)
- # data-science (38)
- # datomic (31)
- # emacs (3)
- # events (2)
- # garden (3)
- # graphql (10)
- # immutant (4)
- # jobs (3)
- # juxt (5)
- # klipse (1)
- # luminus (3)
- # off-topic (40)
- # om (1)
- # onyx (39)
- # other-languages (7)
- # protorepl (3)
- # re-frame (40)
- # reagent (60)
- # ring (8)
- # ring-swagger (14)
- # shadow-cljs (159)
- # spacemacs (1)
- # specter (6)
- # uncomplicate (3)
- # yada (2)
Hi Guys 🙂 In a Clojure / Clojurescript project, with expected shared code, whats the best project structure? Different Projects, Joint project? For the moment theres going to be a mono repo
If it's single deployable app I think the best approach is to keep everything in single repo under different source directories, let's say src/clj
, src/cljc
, src/cljs
@jumar Would cider be able to differentiate between the two projects?
what do you mean by two projects? In that case, there'll be a single project with multiple source directories
i mean, would I be able to setup cider to interact with the clojurescript part separately from the clojure part?
Some time ago I usec cider-jack-in-clojurescript
which created two REPL buffers - one for clojure and one for clojurescript.
And I think cider was more or less able to found proper repl buffer.
Nowadays, I just run cider-jack-in
and if I need to work on cljs part I run figwheel manually and then cljs-repl
Also, looking at the lein project config, it would seem deps are specified per project, how would this work with diffirent deps?
oh that makes sense
If I need both repls at the same time I run cider-connect
and use the new buffer for the other part
awesome
take a look at http://www.luminusweb.net/
especially http://www.luminusweb.net/docs/profiles.md - you can create a skeleton app, e.g. :
lein new luminus my-app +postgres +re-frame
ah, pretty cool! Thanks
hi guys. i got an issue on running 'lein repl' . it shows an error text "Could not find artifact clojure-complete:clojure-complete:jar:0.2.4 in central (https://repo1.maven.org/maven2/)". anyone got the same issue ? thanks in advance!
@rahadianmf this works for me:
lein try clojure-complete/clojure-complete "0.2.4"
well, reading a clojure book I found one interesting statement ( couldn’t be able to understand )
> the lazy seq does not outlive the execution of the function in the form of a closure
If I create a closure with some seq
I could be in trouble ?
with lazy sequences you might run into troubles if you “keep the head” of the sequence
since lazy sequences can be by definition infinite, if you keep reference to any element of the sequence somewhere then the already processed elements cannot be garbage collected
and since it is a sequence that means that any elements after that element you are referring to cannot be GCd
so, if you are “keeping the head” - which means, storing the head element or the sequence itself somewhere - then none of the elements of the lazy sequence can be garbage collected and you’ll end up consuming memory for the whole sequence
not a problem if your sequence has only few elements, but for infinite or otherwise very large sequences that is obviously a huge problem
take for example (doseq [x (range)] (println x))
which will happily keep on printing numbers until the universe dies, your application can keep on going. But if you write it like this (let [y (range)] (doseq [x y] (println x)))
you’ll end up killing your JVM due to out of memory error eventually
@niklas.collin strange, I would have thought locals clearing takes care of that https://groups.google.com/forum/m/#!topic/clojure/FLrtjyYJdRU
I guess it does. Haven’t heard about that before but the lazy heads problem is still there even with that change. My example might actually not die to OOM after reading that part
let me digest your explication @niklas.collin, thanks in advance ! will be back as soon as I digest everything
@niklas.collin oh, you are talking about memory footprint, agree with you . no doubts regarding that. my concern was regarding the statement > the lazy seq does not outlive the execution of the function in the form of a closure we , somehow, lose the closure
using schema (https://github.com/plumatic/schema) with json is better than protobuf?