This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # avi (12)
- # aws (6)
- # beginners (49)
- # boot (140)
- # cider (2)
- # cljs-dev (5)
- # cljsrn (9)
- # clojure (149)
- # clojure-czech (6)
- # clojure-miami (1)
- # clojure-nl (2)
- # clojure-russia (19)
- # clojure-ukraine (1)
- # clojurescript (34)
- # conf-proposals (36)
- # core-async (2)
- # cursive (11)
- # emacs (2)
- # funcool (23)
- # hoplon (2)
- # incanter (4)
- # jobs (1)
- # ldnclj (19)
- # om (47)
- # onyx (5)
- # proton (12)
- # re-frame (20)
- # ring-swagger (17)
- # testing (1)
Boot new 0.3.0 — https://github.com/seancorfield/boot-new — streamlined dependencies, improved built-in templates, expanded readme!
http://seancorfield.github.io/blog/2016/01/29/rebooting-clojure/ -- first of a series
Here's a note on using windows for development. My focus is mostly hoplon, but I figure some of this might have broader interest. First, my environment is windows 10, java 1.8 and lately, clojure 1.8.0. 1. Add BOOT_EMIT_TARGET=no to boot properties with no targe specified. Adding that one line to boot properties means no more mapped files by jetty. Windows will not delete a file that is open, unlike unx systems, so this is important when doing boot reload. https://github.com/hoplon/hoplon/issues/80 2. No unit testing with a headless jsvm like phantomJS. Likely the path separator issue. crisptrutski/boot-cljs-test#42 3. You can't use shared webworkers with boot reload. adzerk-oss/boot-reload#57 4. You can't use cljc files or cljc libraries with watch. boot-clj/boot#397 So, as a windows dev I am just managing. But I would not recommend it just yet!
There are 3 basic issues with windows: 1. File separator issues. 2. Deleting open files is not supported, even if they are mapped like Jetty does. 3. Windows will apparently not let you delete read-only files. I understand that a lot of other problems with using windows have been taken care of by moving to windows 10. But the above 3 remain.
Hmm, I don't quite understand the first issue. What do you mean "no more mapped files by jetty"?
Apparently jetty will use mapped files when it can. Not specifying target files apparently disables this. But please talk to @micha for specifics.
I wonder if this fixes 3.: https://github.com/adzerk-oss/boot-reload/commit/e16ea903a0e003dcfbe82fc05644ab36dbbfc26e
I don't think the check needs to be done in so mane places that it would need a macro 😄
Wouldn't probably solve this. Boot-reload code doesn't access
window itself but calls some Closure code which does it.
@juhoteperi: how do you feel about changing boot to use path URIs internally instead of path strings, like in the fileset etc
that would be a non-breaking change for unix users, and a breaking change that fixes things for windows users
it's crazy that on windows if
foo\bar\baz.clj is a file on the classpath then you access it via
Might be good to start by listing API calls and tasks using paths. Besides
sift comes to mind.
I think it would be best to say that they are always matched against URI's with "/"
Oh, I was wrong, boot-reload does access
window directly: https://github.com/adzerk-oss/boot-reload/blob/master/src/adzerk/boot_reload/reload.cljs#L8
Probably the only problems are with functions that take string parameters? (or regex)
and even trickier because the backslash uris might actually work in ie, but i'm pretty sure won't work in chrome or ff
@laforge49: I'm going to do boot-reload release today, I tested that the change fixes web workers for me, but would be great if you can also check that it works for you.
Sorry. Busy the rest of the morning. Easy enough for me to test, but will need to wait until later. But why not do a snapshot for now? I really don't think that there is that pressing a demand for this.
all ye boot ppl. we are planning to get rid of the annoying thing that you have to define cider-nrepl dependency manually for cider (and hopefully clj-refactor as well). when you
jack-in in with cider we can easily modify how
lein is run like this:
lein update-in :plugins conj "[cider/cider-nrepl \"0.11.0-SNAPSHOT\"]" — repl
i am aware of
boot.repl/*default-middleware* atoms and also the
-d switch but is there a cli way of injecting nrepl middleware plugins at boot start up?
would it be possible to have a switch which can be used to modify
and also if you have any advice for the general repl api design that would be welcome, too
sounds good. nrepl middlewares: they are really difficult to get your head around. but will have a look.
Hmh, even cooler would be if tools.nrepl would allow adding new middleware on runtime. Then it would be possible to automatically add middleware to nrepl started from command line.
yup you can add dependencies at runtime. but I doubt that would work with a middleware
but I don’t see a big problem adding them at start up. it seems both leiningen and boot already have the machinery for it and i don’t see any big blunders with it either… perhaps missing something...
Looks like nrepl server just needs a handler function and the function could do anything
Like Boot could set up a handler function which checks a
atom for a middleware and uses those
But yeah, probably just better to set them up on start up. I was just thinking if there was a way which would work when manually starting the repl.
Though I'm not sure how people use Boot with Cider jack-in because often Boot projects have a single
dev task which does other things besides starting nrepl server
so i can set it up how i want, since i use environment variables to configure things usually
hm.. see your point I guess. so would be nice to add middlewares to already running repls when you are connecting to an already running one
But I still prefer using just normal terminal, in case I for some reason want to restart vim
oh yeah, my vim gets all confused if i do git stuff outside of vim, and i have to restart it or deal with all the "this file changed" nonsense
Heh, usually there is no problem as long as you remember to also commit stuff to git, and add notice that it has been applied to prod using repl 😄
btw I posted a summary of your points about the value of adding middlewares to an already running REPL to the above quoted issue
debugging the initial deployment can sometimes be much easier if you have a repl going in the production app, for sure
yeah we have a microservice where i work now which in case of an error stops listening to the event stream it works with but keeps running so we can REPL in and investigate with all the in memory state intact