This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # beginners (11)
- # boot (148)
- # cider (74)
- # cljs-dev (31)
- # cljsrn (30)
- # clojure (55)
- # clojure-berlin (15)
- # clojure-greece (1)
- # clojure-japan (18)
- # clojure-poland (35)
- # clojure-russia (72)
- # clojure-spec (35)
- # clojure-uk (34)
- # clojurescript (134)
- # cursive (26)
- # datomic (42)
- # dirac (7)
- # editors-rus (1)
- # emacs (17)
- # hoplon (29)
- # jobs-rus (3)
- # juxt (1)
- # luminus (11)
- # off-topic (9)
- # om (66)
- # onyx (49)
- # pedestal (1)
- # perun (19)
- # proton (13)
- # protorepl (5)
- # re-frame (31)
- # reagent (13)
- # ring (2)
- # spacemacs (1)
- # specter (40)
- # spirituality-ethics (2)
- # test-check (41)
- # untangled (7)
- # yada (17)
what is the fastest/easiest way to get a library like cljs-time running in a repl using node?
I now have this in a script, which is already quite amazing:
boot -d clj-time repl -e "(require '[clj-time.core :as t])", but I wonder if I can cut the startup time using node and clojurescript
promoted it into a SO question: http://stackoverflow.com/questions/38636492/repl-session-for-a-clojurescript-library-in-the-vein-of-lein-try
planck -c ~/.m2/repository/com/andrewmcveigh/cljs-time/0.4.0/cljs-time-0.4.0.jar
@borkdude: If you want to reduce startup time with Planck, add a
-K, as in:
This reduces it from 2.2 s to 0.4 s. There is evidently an odd issue with the printing of the timestamp.
planck -Kc ~/.m2/repository/com/andrewmcveigh/cljs-time/0.4.0/cljs-time-0.4.0.jar -e "(require '[cljs-time.core :as t])" -e"(t/plus (t/today) (t/days 100))”
@martinklepsch: ah, that works indeed. I wonder why "planck -c
boot -d com.andrewmcveigh/cljs-time:"0.4.0" show -c" doesn't work...
@borkdude See http://planck-repl.org/dependencies.html where an example using backticks is shown:
$ planck -c`boot show -c`
I used the backticks like this:
Sorry, some Slack formatting issue 🙂
planck -c `boot -d com.andrewmcveigh/cljs-time:"0.4.0" show -c`
boot show -c has a bunch of boot stuff, not sure if that might mess with Planck
(You essentially want to run Boot, but if your goal is outright speed, see the caching portion on that page.) And @martinklepsch is right, minimizing the number of JARs on the classpath will result in Planck finding the deps faster.
planck -c ~/.m2/repository/com/andrewmcveigh/cljs-time/0.4.0/cljs-time-0.4.0.jar -e "(require '[cljs-time.core :as t])" -r does exactly what I want, so thanks
@mfikes: an option akin to boot's
--dependencies that expects jars in
.m2 might be a nice affordability 🙂
@martinklepsch: Yes, it is tempting to add that. (The key is to only expect the JARs to be there, without actually trying to download them, which is another whole project in and of itself.)
well, more like
planck -d com.andrewmcveighcljs-time:0.4.0 — picking newest might be unexpected because it can't download jars
@borkdude: there are alternative things for
boot show -c around that just dump the jars of actual dependencies minus boot stuff
boot -d org.clojars.micha/boot-cp -d com.andrewmcveigh/cljs-time:"0.4.0" with-cp -w --file .classpath
@mfikes: you might want to update the docs with this instead of the default boot show?
@mfikes: if you update the docs, make sure you mention that the user then needs to pass the contents of the classpath file to the
-c option @borkdude
@borkdude: No. Planck will satisfy dependencies by first finding them in the Planck binary. So, you can’t inadvertently specify an alternative version of ClojureScript, for example. The only real danger would be in somehow obtaining a
.clj macro dep from the Clojure JAR, but Planck should be taking care of that in the same way.
@martinklepsch: Yeah… it appears to be a good way of caching the classpath in one step. As opposed to using
tee as is documented in this example:
if [ ! -f .classpath ]; then classpath=`lein classpath | tee .classpath` else classpath=`cat .classpath` fi planck -c $classpath
@martinklepsch: can you explain how it's using caching when you're not writing it to a file?
@martinklepsch: well, calculating dependencies takes time, that is why it's being cached in the
I’m guessing @borkdude that what might help is to point out there are two things that could be cached. (1) The result of building the classpath. (2) The results of compiling the dep.
@micha as in make
show -c only return the project classpath? (excl. any boot stuff)
planck, or, alternatively
-k some/directory/to/write/cache. (`-K` creates and writes in
@mfikes: thanks, was still using an older version of planck where -K didn't work. Now I tried it
Cool. Yeah, you should definitely see it speed up. And you should see a
Also just explaining what that boot invocation does might be good, looks kinda overwhelming if you don't know what's going on 🙂
I’ve created a ticket capturing stuff so I can go back in later and update the docs: https://github.com/mfikes/planck/issues/343
@mfikes: I found out that -K and --cache don't work nicely together, probably a warning would be good
I'm using this script now at the end of this gist: https://gist.github.com/borkdude/8d43941031518a0a85f9732c270b119a
As I think this is cljs related more than om I ask here: after advanced compilation I'm not able to access value of text field by-id. I get
Uncaught TypeError: Cannot read property 'Ub' of undefined, may add that these text-fields are generated in sequence, which I believe contributes to this issue. Any ideas for workaround?
ok, but I must point out in the following code, it works in figwheel. And accessing text data in fn (since this is material-design text field), also works in figwheel dev-env.
mapv #(material-ui/text-field :on-change (fn  (let [id (str "text-field-id-" %) input-text (str (.-value (gdom/getElement id))) valid? (tax-id-validator input-text)] ...etc....)) (range (:text-field-count (om/get-state this)))
I'm getting an "undeclared Var" warning that seems to be coming from a macro. Is there a way to see the compiler's result after macroexpanding my code?
So I’m new to clojure and functional programming in general. I feel like I’m creating a mess while attempting to manage state and I’m wondering if you folks have any suggestions for me. I’ll explain my situation in more detail...
I have a form, which has a message that displays information to the user depending on whether the form is valid, an error occurred during submission, submission succeeded etc
I’m using reagent, and I create a message atom when my component is initialized. In order to update the message I have to pass it through several layers of event handler functions
Is this “normal”? I feel like the number of arguments that my functions take is growing as the complexity of my app increases
so the atom gets passed to a
submit function, and then the
submit function passes that same atom to a
handle-success function and so on
Does reframe have some convention for managing state at a component level? I feel like this becomes necessary when dealing with forms
yes, you have a centralized app-db that stores all of your state and you access it via subscriptions in your components where that state is needed
So let’s say I have an input component which has a valid state. Does that state move into app-db?
without something like this, then yes you have to pass references to your state atoms to wherever they are needed
okay nice, well sounds like I’ll be looking into re-frame sooner than I expected
@danielpquinn: I learned reagent through using re-frame and it really is a good way to start with it - I knew nothing about react or reagent and it was my first real project using clojure and clojurescript. If you go through the readme and the wiki (including the section on reagent) it should give you a really good start as well as a lot of good info on reagent. There is a #C073DKH9P channel on here as well that is very helpful for when you run into questions.
are there any downsides of re-frame subscriptions like
(register-sub :get (fn [db [_ key]] (reaction (getx @db key))))
@micha is there a ticket I can watch for this update? https://clojurians.slack.com/archives/clojurescript/p1469712478001202
otherwise i hope to have a patch release of boot which will notify in #C053K90BR here on slack and #boot_clj on IRC
@richiardiandrea: that one seems promising, I wonder if it’ll be too much of a perf hit
showdownjs effectively, I don't remember that particular use case now, but you can have a look here: https://github.com/Lambda-X/cljs-repl-web/blob/devel/src/cljs/cljs_repl_web/markdown.cljs