This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-16
Channels
- # admin-announcements (3)
- # arachne (9)
- # beginners (10)
- # boot (56)
- # cider (4)
- # cljs-dev (5)
- # cljsjs (4)
- # cljsrn (3)
- # clojure (146)
- # clojure-austin (9)
- # clojure-greece (3)
- # clojure-poland (14)
- # clojure-russia (1)
- # clojure-uk (19)
- # clojurescript (46)
- # cursive (16)
- # datomic (21)
- # emacs (38)
- # events (2)
- # flambo (1)
- # garden (3)
- # hoplon (41)
- # jobs (1)
- # keechma (87)
- # off-topic (2)
- # om (62)
- # om-next (4)
- # other-languages (7)
- # pedestal (6)
- # protorepl (1)
- # reagent (3)
- # rethinkdb (1)
- # ring-swagger (1)
- # rum (3)
- # spacemacs (2)
- # specter (12)
- # test200 (2)
- # untangled (12)
So I set up Boot to compile to compile CLJS and all works fine and dandy (build.boot: https://www.refheap.com/119124). What I don't really get it where to put my .html file that contains a <script src="main.js"></script>
tag? What I've seen googling is to add middleman, a ruby lib (which also means running jruby and this ruby framework - a bit overkill?). How is this usually done by boot clojurescript programmers?
@codemartin: Just place the html file in some resource-path folder and serve using a http server (for example boot-http)
Does someone remember if some Boot tasks uses Clojure.tools.namespace to reload changed namespaces? All current test tasks seem to use pod pools
@juhoteperi: i think @danielsz's system tasks can do both
@micha: Yes, I found that. It doesn't run c.t.n inside pods but it helped me to right track.
Is there any way to fail a task without throwing an exception?
I'm writing a test runner so I need the process to fail when running in CI but when running with watch
I'm handing displaying the errors inside task so throwing an exception adds unncessary cruft to the output
how can i copy files from the checkouts dir to a subdir of the fileset? i’ve got code that uses add-asset to put the checkout dir contents into the fileset, but i have multiple checkouts, and each must go under a “module” name, e.g. target/greetings/ rather than just target/. i could write code to explicitly copy checkout contents to a tmp dir, and then add-asset that, but there must be a better way.
basically you probably need some kind of file that describes the contents of the "module" package
it needs its own package descriptor file, like how war files have web.xml, maven jar files have pom.xml, your thing needs some file too
I had to add a option to select if the task should throw exception (so the process exits with failure) or if the task just doesn't call the next handler
that looks great
And now it actually works!
Took me an hour to notice I was using wrong namespace for error keys
Running single integration test namespace takes "only" 10 seconds
I remember having seeing here, but is it possible to execute an arbitrary (require ...)
directly from the boot
cmd line? I am working on a cider feature and I would like to include a task definition from the cmd line...
I know that repl
can initialize things, but what about a bare boot
command?
Deraen, nice, prettier than mine for sure 😉
also I was thinking that now my parellel test feature is kind of clunky as you need to define a task containing the tests, ...probably it can be improved...
I also discovered a bug that I am fixing as we speak
Oh, right boot.test was included in core 2.6.0
Or was that for testing boot itself?
@juhoteperi: it can test clojure.test
stuff in general, collecting the summaries of the parallel executions
you just need to include the is
, testing
...in a deftesttask
...a build.boot
sample is in boot/boot/core
Looks useful for testing Boot tasks
yes, but it can test anything
Yes but boot-in-boot is unnecessary for testing libraries and applications
definitely right
Hey all, I have a questions regarding a common boot practice of wrapping constants in + signs
does that have any specific meaning in clojure or is it just paying homage to common lisp naming conventions?
I think it's an awesome convention, and I'd like to start using it more if it's idiomatic
@juhoteperi: another disadvantage of boot-in-boot is that at the moment it does not accept dependencies, so the tests should be required in build.boot
in order to be visible (in the "main" pod so to say)
@juhoteperi: boot-alt-test is sooo nice. Thanks!
yeah it is very nice, I am considering adding it to lambone
by default