This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (33)
- # boot (58)
- # cider (21)
- # cljs-dev (197)
- # cljsrn (112)
- # clojure (136)
- # clojure-belgium (5)
- # clojure-dev (57)
- # clojure-greece (1)
- # clojure-italy (3)
- # clojure-russia (6)
- # clojure-spec (148)
- # clojure-uk (54)
- # clojurescript (29)
- # cursive (24)
- # datomic (36)
- # devops (4)
- # emacs (11)
- # figwheel (1)
- # graphql (18)
- # hoplon (6)
- # leiningen (2)
- # luminus (4)
- # off-topic (7)
- # om (4)
- # onyx (27)
- # precept (1)
- # protorepl (12)
- # quil (1)
- # re-frame (28)
- # reagent (10)
- # ring (9)
- # robots (1)
- # rum (2)
- # slack-help (5)
- # spacemacs (16)
- # sql (16)
- # untangled (16)
- # vim (3)
- # yada (2)
@minikomi I don't think it is, there is no stable version after all.. I am waiting for a fix in Figwheel before releasing (btw that needs a Windows machine test 😀): https://github.com/bhauman/lein-figwheel/pull/537
@sooheon Don't you need a bunch of JVM options enabled on the process you're trying to connect to?
You'll need to specify those options in the
BOOT_JVM_OPTIONS environment variable I think...
For example, see options described here https://stackoverflow.com/questions/28765144/how-to-connect-jmc-java-mission-control-to-remote-jvm-in-ubuntu
(I know this isn't a remote connection situation but I suspect some of those options are likely needed here?)
These two options are required:
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder, but even with these I get the same error complaining about “using the correct protocol on the Service URL (service:jmx:<rml://127.0.0.1/stub>…”
They are multiple instances of clojure inside the same jvm. Each have their own list of dependencies.
If I’m just creating tasks inside my own project, is there an advantage to using them?
Only if your tasks have dependencies that aren't used within your project (e.g. sass4j for compiling sass)
I always get
boot.pod/call-in* pod.clj: 413 ... org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke ClojureRuntimeShimImpl.java: 102 org.projectodd.shimdandy.impl.ClojureRuntimeShimImpl.invoke ClojureRuntimeShimImpl.java: 109 ... boot.pod/call-in* pod.clj: 408 clojure.core/read-string core.clj: 3687
A newbie question. I want to download a file and keep it between builds (the file is a tool I need during the build). My understanding is that I should put it into
(cache-dir! ::tools-folder). Then I can store the path to the file inside fileset's
:metadata. And then any task can get a path to the tool using the metadata. Is this correct?
I found boot's documentation to be incomplete in many areas (or maybe this is just me?).
@manenko maybe, the community does its best to keep it up 😀 you can either open an issue with the things you think are missing or directly PR and therefore contribute to it. Both are super welcome 👍
Absolutely, I will contribute into documentation once (if) I'll learn how to write various boot tasks
For example, imagine someone who is not familiar with boot. They want to write some tasks and guess where they are looking for a guide? Right! It's there https://github.com/boot-clj/boot/wiki/Task-Writer%27s-Guide Except that it doesn't help much 😞
manenko: boot is pretty much a "read the source, Luke!" project until we get more complete docs. fwiw the way i learned was by reading (stealing) code from community libs. and then asking qs on slack..
i’m trying to evaluate some cljs.spec code with generators using vim-fireplace and the cljs-repl boot plugin. there are a lot of moving parts here, so i’m not sure where to look for debugging. essentially when I try to
cpp broken code like
(1 + 1) I dont get a stacktrace error, I get something like this:
0.2.2 changelog mentions:
The current nREPL's session's *e binding is now set properly when an uncaught exception occurs. but I'm not sure if that helps with this case
I see. now that you mention it part of my problem could be i’m not actually in the cljs repl trying to eval that code, i’m 1 level up in java repl >.< (doh)
There was at least this commit in fireplace re cljs stacktraces some months ago: https://github.com/tpope/vim-fireplace/commit/024ff4f1231a10c6427470d07001ad1b6fbcdb5a
Also, my experience with fireplace and cljs repl is the same with figwheel also so I think the problem is not in boot-cljs-repl
as if the error emitted by the code evaluation is swallowed and another rhino error is thrown instead, or perhaps the error leaks into the evaluator instead of being captured at all, which itself throws a new error?
I'm just trying to build a jar file that will hold some CSV files for a simple data collection script
That is, the jar will hold my clojure code with a -main function that should be executed along with the CSV files