This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-12
Channels
- # admin-announcements (8)
- # alda (11)
- # announcements (53)
- # architecture (2)
- # aws (10)
- # beginners (69)
- # boot (403)
- # braid-chat (160)
- # cider (10)
- # cljs-dev (14)
- # cljsjs (26)
- # cljsrn (34)
- # clojure (223)
- # clojure-art (1)
- # clojure-brasil (4)
- # clojure-dev (10)
- # clojure-france (1)
- # clojure-gamedev (1)
- # clojure-nl (14)
- # clojure-russia (20)
- # clojure-seattle (8)
- # clojure-sg (1)
- # clojurebridge (2)
- # clojurescript (156)
- # code-reviews (2)
- # community-development (305)
- # cursive (5)
- # datavis (33)
- # datomic (38)
- # devcards (4)
- # dirac (39)
- # dunaj (3)
- # emacs (5)
- # events (2)
- # funcool (45)
- # hoplon (3)
- # instaparse (24)
- # jobs (2)
- # ldnclj (77)
- # lein-figwheel (4)
- # leiningen (1)
- # mount (49)
- # nyc (14)
- # off-topic (52)
- # om (125)
- # omnext (4)
- # onyx (13)
- # other-lisps (1)
- # overtone (8)
- # parinfer (31)
- # plastic (6)
- # portland-or (3)
- # quil (4)
- # re-frame (6)
- # reading-clojure (16)
- # reagent (212)
- # ring-swagger (11)
- # robots (5)
- # spacemacs (4)
- # specter (1)
- # yada (26)
another question, is there a zeal/dash docset for boot?
@richiardiandrea: not that i know of but that would be awesome
@alandipert: definitely! We'll schedule it for the next free time slot
A question, when I call pod/with-call-worker
in a boot repl session, which classpath can I see in the call?
for example I see boot.core
...but do I see a custom namespace?
boot starts up a singleton pod for its own purposes called the "worker pod"
it's where dependencies for various tasks live
task implementations, rather - like jgit
with-call-workr runs things in there, probably not what you want to use in yuor own project. the classpath you see is the worker's
https://github.com/boot-clj/boot/blob/master/boot/worker/project.clj - libraries in the worker pod
oh ok, that is why all the calls were wrapped, I am importing jgit
and using it, I guess I do not need a custom pod for this right?
not necessarily, but i would say if you needed things in addition to jgit, probably best to make your own pod
so as to not cause problems with the rest of boot
my project is basically about a custom task that will use jgit, I don't think I am going to use more than this
how and when there can be a conflict? in case the caller of my task is itself using jgit
right?
to mess things up you'd need to add more dependencies to the worker pod
which is not an especially easy thing to do so i wouldn't worry about it
boot.pod/add-classpath would be the way to do it
ok, I am just trying to baby understand whether I need to create my own pod when my task uses external jars like jgit
the caller of my task will have jgit
on the classpath right, another way to say this is, is each task you require executed in its isolated pod automatically?
i see what you're getting at
are you learning clj along with boot or have you been at it for awhile?
at it for a while
ok cool
so yeah the way we tend to do it is to make a pod in a closure that closes over the function users call
like (let [x (atom 0)] (defn inc! [] (swap! x inc)))
except make-pod
instead of atom
ok, so one unique pod for all the call chain
yeah. for efficiency we have a pod-pool
thing
that's conceptually similar except maintains a pool of warm pods
right, I read about it in the wiki
so practically each "custom" task that has transitive dependencies, adds them to whatever classpath/pod the caller has
(deftask inctask []
(let [p (future (boot.pod/with-eval-in (boot.pod/make-pod (boot.core/get-env)) (def n (atom 0))))
pod-inc! (boot.pod/with-eval-in @p (swap! n inc))]
(fn [next-handler]
(fn [fileset]
(println "The number in the pod is now: " (boot.pod/with-eval-in @p @n))
(next-handler fileset)))
def n
var in the pod isn't visible in the rest of the program
and right
wow cool stuff 😄
on the 2nd line of that example when the pod is made, it starts with whatever the user's environment is set up to be
then usually we add our own task-specific dependencies to that
https://github.com/adzerk-oss/boot-template/blob/master/src/adzerk/boot_template.clj is a slightly more involved example
ok great so in theory if I want to be clean I should create a new pod where I add jgit
and use it in the pod only
correct
you can then either run code in the pod directly with with-eval-in
, or you can require namespaces in the pod. the latter is good if you have a lot of code to run in the pod
or my caller, if she is going to include jgit
as well, will have a clash
yeah. you may choose to start your pod with (dissoc (get-env) :dependencies)
then you pick up the environment minus any dependencies, which could include jgit. another option is detecting if jgit is already loaded and not loading it into your pod if so
yes but I would depend of whatever version my caller/boot has
emptying the env
is scary because I then need to include back all the deps that jgit
needs
but I guess I need to do it anyways
yeah it's easy - (-> (get-env) (assoc :dependencies '[[jgit ...]]))
are ya ready for the slackpocalypse? https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=slackpocalypse
@jethroksy: how do you like arch? a friend of mine keeps suggesting i switch
i do a custom bspwm setup on my home desktop, but if you're too lazy you could always install any DE
ill have to give it a go sometime
@seancorfield: hey, just wanted to see how the https://github.com/seancorfield/boot-new idea is going ( selfish reasons )
I hope to put up a first cut this week. I had hoped to do it last week but life got in the way.
@martinklepsch: > wouldn't it make sense to use boot for local installation as well if you're already using it for everything else?
@martinklepsch: I finally did it. Hopefully for the better...
@martinklepsch: https://github.com/magomimmo/modern-cljs/blob/master/doc/second-edition/tutorial-20.md
@magomimmo: very cool that you are updating all your tutorials
@meow: yep. I’m thinking about the next steps….probably test.check, then the reactive stuff...
How do I do the equivalent of :repl-options {:init (set! *print-length* 50)}
(in leiningen) in boot? (task-options! repl {:init-ns 'notification-sender. core :eval (set! *print-length* 50)})
fails due to "Can't change/establish root binding of: print-length with set".
:eval isn't quite right either as I want it to happen in my init-ns and not in the boot namespace, but it was the closest I could find in https://github.com/technomancy/leiningen/blob/master/sample.project.clj for in-line evaluation
sorry, meant this link: https://github.com/boot-clj/boot/blob/7605a731902a77b577ad1aa869166612568d866d/boot/core/src/boot/task/built_in.clj#L287
I also found this http://blog.michielborkent.nl/blog/2015/06/06/from-leiningen-to-boot/ which suggest :eval '(set! *print-length* 50)
in task-options for repl, which makes sense, but that still doesn't change the print-length var once booted.
Hmm, I'm not sure how to properly set it in boot, but I remember setting this can cause some startling errors in things that rely on pr-str
and then being able to read-string
it.
I think sending objects to boot pods was one thing like that, so I'm unsure if setting this is a good idea.
@jaen: seems strange to me that print-length would affect pr-str, almost like a bug if so?
@oskarth: you mean you have the set! call in :eval and it's still printing more than 50lines?
@martinklepsch: yes, *print-length*` => nil
@martinklepsch: I might be misremembering exact functions, but I'm pretty sure someone had an issue with that. If free slack had full search...
How are you connecting to the repl server?
printing too large collections causes spacemacs to crash multiple times a day, so pretty useful feature 😛
Try in a directory without build.boot and all specified via cli maybe
And you have a top level task options call?
why would that make a difference? the problem is just how to instrument boot to do init repl-options, no?
Just trying to reduce surface area :)
@martinklepsch: seems I wasn't misremembering.
boot.user=> (pr-str [1 2 3 4])
"[1 2 3 4]"
boot.user=> (set! *print-length* 2)
2
boot.user=> *print-length*
2
boot.user=> (pr-str [1 2 3 4])
"[1 2 ...]"
Are there other fns that do the same thing as pr-str but without pr
?
@oskarth: I can give it a try here in a bit
Not that it is a right way to serialise things, but I remember someone raising an issue here on slack that something broke
I guess those things shouldn't use pr-star in the first place the.
Just something for you to be aware of. It might help you when you get an inscrutable error like that guy back then.
As for serialising Clojure without pr
- I suppose you're only left with external libs like EDN or something. But I don't know the whole stdlib by heart.
Hmmh. If I have direct ClojureScript dependency with test scope, uber task will still include clojurescript dependency, probably because some other dependency has transitive dependency to clojurescript.
Found it, starts at the bottom of the first link, the *print-length*
being the reason is at the start of the second.
http://clojurians-log.mantike.pro/clojurescript/2015-11-19.html
http://clojurians-log.mantike.pro/clojurescript/2015-11-20.html
Also another related issue - https://github.com/boot-clj/boot/issues/218
@oskarth: also this last link (the issue) seems like something that can be an answer to your question.
@juhoteperi: that's an interesting thing, do you think uber
should add :exclusions
?
@micha: Not sure, it is sometimes possible that some dependencies really require something that is in test scope in project
Could be
yeah i think in the uber case you're not making a library that has dependencies of its own anyway
At least I wouldn't probably add any more logic
In case one wants to optimize uberjar size, I think it's best to sift the fileset
We are already using test scope for things which it is not supposed to be used
Maybe. But I guess it doesn't matter that we are using it for build deps.
also i think a better way than :scope "test"
might be to use the :dependencies
option in the pom
task
"This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases."
We are not strictly using it for test compilation and execution
i used to think it was a good way but especially with like boot-cljs you can see the limitations
@micha: and @juhoteperi in the latest tutorial of modern-cljs I briefly wrote about dependency scope. Hopefully I did not write something wrong (it’s a complicated topic). It would be a pleasure to have your comments, specially if I wrote something less than accurate. https://github.com/magomimmo/modern-cljs/blob/master/doc/second-edition/tutorial-20.md#dependency-scope
is there a boot equivalent to lein's :pedantic? :abort
?
@magomimmo: keep up the good work
@mccraigmccraig: i don't think so
@magomimmo: I do like the sound of that
@micha: I have been great. Busy. Moving on Thursday. Helping with #C0CB40N8K and #C0J20813K
and other stuff https://twitter.com/ErgoAlgorithmic
can we make an exception because the on-boarding process for #C0J20813K is to enter "fuck" into the search box
I don't care much about this, since if I was so easily annoyed by such things then I would probably already be cursing at the attitude the Clojurescript maintainer has, but I've seen people get agitated here when someone used at-everyone or babbled incessantly in general (a non-partable channel). So you might want to take care to not annoy people like that, which self-inserts into so many channels can do. Friendly advice, nothing more.
@jaen @martinklepsch so boot repl
in terminal sets print-length
, whereas jack-in
(using the profile.boot
from step 2 inhttps://github.com/boot-clj/boot/wiki/Cider-REPL) switches the init-ns
but doesn't set print-length
this is using a build.boot
with (task-options! repl {:init-ns 'notification-sender.core :eval '(set! *print-length* 20)})
at the top-level
maybe this is more cider than boot related?
it's not clear to me whether this is a configuration issue with cider or boot, though
if you run the repl task without --server
and check *print-length*
right there?
if I just want to start a nrepl server with boot and connect via emacs, how do I do that?
ah, then just check in the repl that comes up
thought you were using -s
but maybe that was from a prev. message
running just boot repl
works now using profile.boot and setting BOOT_HOME (don't think this worked before)
cider-jack-in
starts a nrepl server for current project, so that seems like a natural thing to try to do manually. How do I do that with boot?
boot repl
boot repl --server/-s
starts a server without a client but they're essentially the same
cider-connect
=> localhost
=> [weird empty screen] 55564
[port of nreplserver] => connection failed
Look, just cut cider out of the equation and see if that works
boot repl
— and then see if *print-length*
is correctly set
still not clear cider per se is the problem, could be something with the order of sending messages when it starts the nrepl server, or that cider is too tightly coupled with lein. I don't know which it is
I don't see where? sorry if so. You can also try doing boot repl -s
and boot repl -c
in different terminals but I believe boot repl
is equivalent
"so boot repl
in terminal sets print-length
" and "running just boot repl
works now using profile.boot and setting BOOT_HOME (don't think this worked before)" - sorry if that wasn't clear
ConnectException Connection refused
upon boot repl -c -H 127.0.0.1 -p 55648
when boot repl -s
is running at nREPL server started on port 55648 on host 127.0.0.1 -
(docs: https://github.com/boot-clj/boot/blob/7605a731902a77b577ad1aa869166612568d866d/boot/core/src/boot/task/built_in.clj#L289-L292)
I wonder if there's something going on with boot and nrepl - does boot actually separate the server and client like nrepl specifies or does it do something else?
Alternatively, could it be that certain packages are required to be in build.boot (outside of those defined in profile.boot) for cider/nrepl to work? I just have my project's packages in there.
Other thing: .nrepl-port
doesn't seem to be set upon boot repl -s
. Could open an issue for this.
and if I edit .nrepl-port
manually and run boot repl -c
only I get "URISyntaxException Illegal character in authority at index 8: <nrepl://127.0.0.1:55875>" which is quite interesting
shot in the dark: is boot up-to-date?
whats up w this braid chat? is the clojure community is trying to switch over to it from slack? i would be happy to try it too. already running gitter, slack, whatsapp, line, wechat, hipchat...
@oskarth: checked out my last link? That issue seemed to have a similar use case to yours and mentioned using the boot-shim.clj
file.
@onetom: Checkout #C0CB40N8K if you’re interested in the whole Slack / Braid / whatever discussions.
Ah right, I thought something is still not working properly and that maybe the shim will work. Sorry if that's not the case.
There seems to be a lot of issues related to nrepl, or maybe my configure is just borked
@martinklepsch: boot version 2.5.5, so seems to be up-to-date (not clear from GH page what the stable etc version is.)
To be honest, there seems to be too much broken around nrepl stuff (see nrepl server/conn / no .nrepl-port set) and lack of documentation (repl options, nrepl stuff) for this to be worthwhile. Already spent too many hours on this small thing. I'm gonna stop now and just hack it for onw.
If the nrepl stuff worked for certain then it'd be easier to see where exactly the problem is, cider or boot or in between
what I mean with nrepl was to separate boot repl into two steps: boot repl -s
and boot repl -c
I'm trying to upgrade to 2.5.2/2.5.5 and my process gets stuck on Retrieving pod-2.5.5.jar from
yeah i guess so, seems like it's just clojure dependencies that are affected though 😄
It does seem to only be happening with dependencies the new version of boot is trying to fetch though
gah x2: 1. boot repl server is started with boot repl -s wait
, not boot repl -s
- explains missing nrepl-port 2. github opens issues before you hit enter
the only built-in tasks that block the pipeline in any way are the wait
task and repl --client
, and watch
another thing that might be relevant is that the nrepl server is running in the same pod as your build.boot
there is no way around loading nrepl itself into the main pod, because you want the session to be in the main pod context
but the repl server will load the nrepl dependency dynamically at runtime if your project doesn't already have an nrepl dependency
so if you're not using the repl task there will be no nrepl on the classpath unless you have it as a dependency in your project
next step is probably to read elisp code for cider-jack-in, see how it works differently from starting a nrepl server and connecting to it
...and I can get boot/pod with boot 2.3.0 installed locally, but not with a boot 2.5.5 docker container
I'm here right now: https://github.com/clojure-emacs/cider/blob/e284271133d5a7d736e457cd587fa598e9ff404a/cider-repl.el#L198 - a lot of non-boot specific things, but my current hypothesis is that repl-options are evaluated differently in the nrepl server/conn lifecycle in lein and boot. Pretty big deep hole for my knowledge of this stuff though.
called from https://github.com/clojure-emacs/cider/blob/f90d31aba97858363d406bd8d7a558e41b786319/cider.el#L227
@micha: Aether is eventually timing out after a long time... I think this has something to do with docker changing ownership in ~/.m2/repository/<pkg>
to root, maybe
"Boot has an option to provide :eval form but only for the client — it doesn't work if REPL is started in server mode."
i think maybe i can add the fix for that as 2.6.0 release, and push the stuff in 2.6.0 to 2.7.0
no, you can just add BOOT_EMIT_TARGET=no
to your boot.properties, or your shell environment variuables
either i'm working in development mode which is all on the classpath, or i'm pushing artifacts to the cloud
yeah when i build a frontend when i]m working on it i don't need a target dir because i have a local jetty server serving from the classpath
and when i deploy the frontend i'm deploying files to s3 or jars to beanstalk or whatever
the implicit target dir brings in some counter-intuitive behavior, like what should boot repl
do? should it delete the stuff in the target dir?
but we have a project with about a dozen tasks, now nearly all of them need (target ...)
i think you'll see some performance improvements with the other tasks if you use the target task
one thing I'm seeing now with 2.5.5 is this warning: cli: option output-dir: expected optarg, got str