This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-11
Channels
- # admin-announcements (10)
- # arachne (2)
- # beginners (74)
- # boot (302)
- # cider (49)
- # cljs-dev (11)
- # cljs-edn (7)
- # cljsjs (13)
- # cljsrn (1)
- # clojure (164)
- # clojure-austin (1)
- # clojure-brasil (3)
- # clojure-finland (2)
- # clojure-greece (4)
- # clojure-russia (48)
- # clojure-uk (11)
- # clojurescript (138)
- # community-development (1)
- # cursive (13)
- # datascript (1)
- # datomic (19)
- # emacs (4)
- # events (1)
- # garden (1)
- # hoplon (123)
- # jobs-discuss (9)
- # keechma (5)
- # lein-figwheel (4)
- # leiningen (2)
- # luminus (15)
- # mount (1)
- # off-topic (8)
- # om (66)
- # on (1)
- # onyx (28)
- # other-languages (2)
- # planck (1)
- # proton (5)
- # re-frame (18)
- # reagent (15)
- # untangled (15)
@richiardiandrea: have you seen Dirac (https://github.com/binaryage/dirac) ? boot-cljs-repl doesn’t allow e.g. eval in the context of a stack frame (breakpoint), or connecting to Cursive IDE REPL.
@superstructor: really you can't? I have to try to connect from cursive..that would be a thing I can improve or add as option
I am familiar with Dirac but haven't tried it myself to be honest
Wow installing it looks pretty articulated
@richiardiandrea: jupl/boot-cljs-devtools
packages Dirac support for Boot.
But boot-cljs-devtools
should probably be in by default
Ah ok all included nice
@richiardiandrea: there is also a channel for #C0J01U7MY
@richiardiandrea: if you were interested in adding support to the lambone template, I’ve got it working with my boot projects already, so I could do a pull request ?
Yes, I still don't know if I want it as default or as option, but definitely!
@superstructor: the fastest patch in the history of GH, I only announced it here basically ;)
is there a way to make sure certain namespaces are added to the classpath by defaut? i see certain ones missing when i run from uberjar if they are not required
the files that will be on the classpath shouldn't have anything to do with what you require
boot-expectations 1.0.9 available — adds -S
/ —startup
option for symmetry with existing -s
/ —shutdown
option, and provides more flexibility than expectations_options.clj
— https://clojars.org/seancorfield/boot-expectations
This may be a #C0617A8PQ question but I figured I’d ask here first… If I want an expression evaluated when I cider-jack-in
to a Boot project, is there a way to do that?
I initially thought I could use the -e
option but CIDER uses boot repl -s wait
and -e
is a client option, not a server option.
@seancorfield: you have to customize...let me fetch it for you
(technically I want the expression evaluated once when I start the server not really when I start the client)
So —init
perhaps?
ok, let me see if I understood, if you want to execute something different from boot repl -s wait
you need to customize: cider-boot-parameters
(setq cider-boot-parameters "cider dev")
in my case
I already have that… I think I was just coming at this from the wrong angle… let me try something...
ah ok 😄
Ugh! No. —init
is also a client-only operation.
uhm yeah interesting problem, now I got what you mean
but I don't have a solution
Is someone here using cursive with boot
? it looks like a colleague of mine cannot see files as Clojure files...EDIT: found https://github.com/boot-clj/boot/wiki/For-Cursive-Users
Answer: just put the definitions I want in build.boot
...
Background: I’m setting up the Reloaded Workflow and wanted to pull in the equivalent of Stuart’s "dev" namespace file… but Boot makes it simpler. Duh!
ah yes that's true, I did the same in lambone
: https://github.com/Lambda-X/lambone/blob/master/resources/leiningen/new/lambone/common/dev/boot.clj#L96 😄
Hi all, probably a silly one but what's the simplest boot file I need to have to have get a clojurescript nodejs repl going?
How can I specify java source code path in build.boot? In project.clj (for leiningen) I can do this with :java-source-paths key in defproject.
@chunsj: any .java files in your :source-paths
or :resource-paths
will be on the classpath for compilation
@juhoteperi: I am trying to use boot-sass to include some CSS files packaged as part of cljsjs component. My deps are:
[cljsjs/react-select "1.0.0-beta12-0" :exclusions [[cljsjs/react-dom] [cljsjs/react]
My style task is:
(deftask styles []
"Compile Styles"
(set-env! :source-paths #{"sass" "cljsjs"}
:resource-paths #{})
(comp (watch)
(speak)
(sass)
(sift :include #{ #"([^\s]+(\.(?i)(css))$)"})
(target :dir #{"compiled_css"})))
And I am trying the following import (And variations on it)
@import "cljsjs/react-select/common/react-select.inc”;
@dimiter: Only .scss. You must define the extension in import if it is something else.
Right, but if it has an extension, the compiler just translates it to a URL Import call.
I have no idea how sass works with this. Less has import options to select how compiler imports the file.
Check out https://github.com/sass/libsass/pull/754 for some background.
I don't think options is needed. This add-ext/find logic just needs some tweaking to check for css files if scss doesn't exist: https://github.com/Deraen/sass4clj/blob/master/src/sass4clj/core.clj#L60-L71
I switched to 2.6.0-SNAPSHOT and now I’m getting a dependency fail. The dep is [com.google.appengine/appengine-java-sdk LATEST :scope "provided" :extension "zip”]
which is available at http://mvnrepository.com. It used to work, now I get “Could not find artifact”. Help?
Even with LATEST it successfully finds the latest, because it’s trying to fetch 1.9.37
The msg is Could not find artifact com.google.appengine:appengine-java-sdk:jar:1.9.37 in maven-central (
I can manually download the zip from http://mvnrepository.com/artifact/com.google.appengine/appengine-java-sdk/1.9.37
no, we just use ASGs with a user-data script that provisions the machine in a very simple way
basically we organize it similar to beanstalks, like we have a git repo for the service that will run on the cluster
then we have some scripts to create ASGs (environments in beanstalk parlance) with a generated user-data script that pulls the repo from s3, loads it on the new instance, and runs the "provision" and "deploy" targets of the makefile
basically we removed all the ruby and python script nonsense and layers of nginx proxies and all that
and there's nothing you can do about it because they lock you out while beanstalk is doing things
@micha very strange. now it’s working again and I have no idea why. maybe I had a network problem?
so we can watch it and if things start going south we can just terminate the new instances
i attended the AWS summit last month, and came back with no new knowledge whatsoever haha
yeah i am staying away from tooling for now, just doing the minimum to get an instance running, then we can program the rest of the way
all the things we move off of chef get easier to work with and stop failing all of a sudden in the middle of the night
reason I'm using beanstalk is because I don't have to jump around all the consoles so much
so our thing we use is just a way to get a unix environment running so your makefile can run
for now my main objective is to clean up my mess so I can leave the company in peace
you put your application on s3 and make a user-data script that pulls it down when a new instance is launched
then you can make a launch config for that ASG to associate it with the user-data script
i prefer the hack because i can at least see what it's doing and change it if i need to
I'm not going to be the one maintaining my mess, so I'm morally obliged to make the process easy
like we have boot building the uberjar, that could get complex if we need to do fancy things at build time
and then once you have the uberjar and an upstart script or whatever to manage it on the instance
the logic involved with bringing up a new instance and getting the service installed and running is trivial
(ns shim
(:gen-class))
(defn -main [& argv]
(require 'my.app.entrypoint)
(apply (resolve 'my.app.entrypoint/-main) argv))
our deployment situation was getting too complicated so we had to ruthlessly remove many things lol
@dominicm: boot-new
supports both Leiningen templates and Boot templates. Not sure what @richiardiandrea meant by his comment in the announcements channel.
I think @dominicm was asking whether boot-new has its own template engine
And boot-new
generators can be used in both Leiningen and Boot projects too.
yes true that
but the question was: why I chose lein templating
boot-new
only loads Leiningen if it is processing a Leiningen template. Leiningen is not used to process a Boot template.
probably then I could have chosen the latter, I will explore what are the advantages of having a boot template
in my mind they were interchangeable
and I chose lein for no rigorous reason
@mobileink: is the dependency issue resolved now? or is there a regression in 2.6.0-SNAPSHOT that needs to be fixed?
but of course boot-new
can generate both so...I don't think there is any problem with that
@micha: seemed to fix itself. i don’t think i made any material changes, it just started working. maybe some kind of network wierdness I guess.
I'd be very interested in suggestions for new Boot-template-only features for boot-new
@richiardiandrea @dominicm
@seancorfield: I think I've misunderstood the term "boot template"
Boot template: https://github.com/framework-one/fw1-template/blob/master/src/boot/new/fw1.clj — currently looks a lot like a Leiningen template but doesn’t use Leiningen.
Back when it was a Leiningen template https://github.com/framework-one/fw1-template/blob/v0.4.0/src/leiningen/new/fw1.clj
The difference is that a Boot template can bring in boot.core
etc and do whatever Boot-related stuff it wants to (but it can’t bring in Leiningen stuff — some lein-templates call get-leiningen-version
etc).
And now having Boot-specific templates (which can generate any type of project, BTW), we can enhance boot-new
separate to Leiningen to add any functionality that Boot users want.
Right now there are very very few Boot templates out there — most folks are using boot-new
to create projects based on Leiningen templates (since boot-new
supports both) — but I’m hoping that will change and folks working with Boot will start producing Boot-specific templates.
I am guilty of that...tbh I did not know about the fact that I could bring boot.core
I've got some Boot+CIDER+CLJS Browser REPL issues that I'm trying to work through, any assistance is appreciated. I'm trying to get the Boot setup from the modern-cljs tutorial working in CIDER, and am trying to figure out how to set up the Boot tasks to get this to work. Not sure if here, #C0617A8PQ, or #C03S1L9DN will be the best place to ask, so am starting here today.
The dev
task looks like (comp (serve) (watch) (reload) (cljs-repl) (cljs) (target :dir #{"target"}))
CIDER launches boot with repl -s wait
as its parameters, and injects the cider-nrepl and refactor-nrepl middleware. Just adding dev
before the other parameters doesn't work...boot doesn't load the middleware.
My end goal is to have two REPL buffers, one for CLJ, one for the CLJS browser REPL.
This is the command that CIDER synthesizes: boot -d org.clojure/tools.nrepl\:0.2.12 -d refactor-nrepl\:2.3.0-SNAPSHOT -d cider/cider-nrepl\:0.13.0-SNAPSHOT dev repl -m refactor-nrepl.middleware/wrap-refactor -m cider.nrepl/cider-middleware -s wait
I figure it was something along those lines, but my boot-fu is low. Can you calve off a child task so the rest won't block?
Yeah, there's a lot of magic under various covers.
I ccan definitely remove the wait from the defaults and see what that does.
Is there a Gitter room for Boot?
I think I've figured out a bit of the issue, at least, by running the boot command from the command line...it's starting up two nREPLs, and the first of them isn't getting the middleware added.
Or the second, depending on the order.
Also, am getting Warning: version conflict detected: org.clojure/clojure version changes from 1.2.0 to 1.7.0
. boot show -p
shows that version is probably coming from tools.nrepl. Not sure why the clojure version of 1.7.0 in boot.properties isn't overriding it?
Adding an extra -d
to link in 1.7 fixes that warning, at least.
boot-mvn? my use case is creating EAR apps. I use uber -j
to pull transitive deps from the foo dep and put them in foo/WEB-INF/LIB, then I use a custom task to pull everything else and put it in the right place, since I couldn't figure out how to do that with uber. is it worth the trouble to write a task lib for generally inspecting / extracting maven artifacts? anything out there that already does this?
Not that I know of, but let's wait for other opinions
I suspect the EAR use case (which is actually the GAE modules use case) is an outlier. But I often find myself dumping maven jars just to see what's in there, and typing out the ~/.m2/...
path gets old. Maybe there's a better way I don't know about.
sth like $ boot mvn/show -c foo/bar:0.1.0-SNAPSHOT
might be handy. maybe also a set of switches like for sift, to extract stuff and put it into the fileset.
@mobileink: the war
task doesn't do what you want?
for a sec I thought "this is where I find out I've embarrassed myself again". I completely forgot about war
. but I suspect it won't do (away from my machine, can't test.) The EAR project ( as I'm calling it) has no code, just some xml config stuff (which could be made EDN). So the build uses the maven jars to populate the war subdirs. that includes copying the transitive dep jars etc. and each maven component must be handled separately; the component wardirs are effectively independent (they could be implemented in other languages!) so it's entirely driven by build.boot and the maven jars
I published the results of my research around code reloading and thought this might be of interest to some here present: http://danielsz.github.io/2016/05/06/Ghosts-in-the-machine
I think this will turn out to be great exam of boot. with the build stuff offered bt google the components are subprojects of the modularized webapp. with boot they can be completely independent and so easily reusable across modularized webapps
very cool indeed
@micha: Both are warranted currently. Code reloading is desirable every time you make a change to source code to have the current definitions in memory. Because sometimes Vars can get "trapped" in threads (typical scenario is the handler you passed to the HTTP server), you would need to restart the whole system. This is why the boot-system
task allows for both reloading and restarting.
The new implementation is pretty awesome if I may say. I'll release it next week. If you mark a namespace with :blood-of-spring-lamb, the reloading mechanism passes over it (Passover).