This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-17
Channels
- # beginners (52)
- # boot (116)
- # cider (21)
- # cljs-dev (44)
- # clojure (104)
- # clojure-dev (82)
- # clojure-greece (5)
- # clojure-japan (4)
- # clojure-nl (14)
- # clojure-russia (65)
- # clojure-serbia (3)
- # clojure-spec (38)
- # clojure-uk (9)
- # clojure-ukraine (1)
- # clojurescript (65)
- # clojurewest (1)
- # community-development (1)
- # core-logic (3)
- # cursive (5)
- # data-science (9)
- # datomic (13)
- # emacs (45)
- # euroclojure (1)
- # hoplon (2)
- # instaparse (23)
- # javascript (1)
- # jobs (2)
- # klipse (43)
- # leiningen (8)
- # lumo (25)
- # off-topic (7)
- # om (13)
- # om-next (3)
- # onyx (11)
- # pedestal (12)
- # planck (19)
- # proton (1)
- # re-frame (26)
- # reagent (26)
- # remote-jobs (13)
- # ring-swagger (23)
- # spacemacs (1)
- # untangled (3)
@residentsummer That is indeed a troublesome issue! I'm looking into it atm; I'll let you know if I find a solution
@residentsummer Sorry about taking so long; anyway, it turns out this is a really easy fix: instead of running boot repl
and then evaluating (boot (watch) (refresh))
in that REPL, just start off the whole thing at once using boot repl -s watch refresh
! Then you should get more informative stack traces.
I’ve run into trouble with boot-cljs. with optimizations none, the paths in the main js file are relative; they look like this:
if(typeof goog == "undefined") document.write('<script src="greetings_hello.out/goog/base.js"></script>');
document.write('<script src="greetings_hello.out/cljs_deps.js"></script>');
But I need absolute paths, since my code is componentized and must be runnable from any page. However using :asset-path results in loss of the “greetings_hello.out” bit.For example, if I set :asset-path “resources”
(in my cljs.edn file) the result is:
if(typeof goog == "undefined") document.write('<script src="resources/goog/base.js"></script>');
document.write('<script src="resources/cljs_deps.js"></script>');
And similar if I use “/resources”. But ”resources/goog/base.js"
does not match the structure, the code is still in e.g. greetings_hello.out/goog/base.js
.
It looks like this is just the way the Clojurescript compiler operates. If you set :asset-path, it will affect what gets written in the main js file, but it will not effect output-to or output-dir; the implicit assumption is that you will move the files as needed.
But you can make this work by setting all three options, e.g.
(cljs.build.api/build "src"
{:main 'hello-world.core
:asset-path "/resources"
:output-dir "resources"
:output-to "resources/main.js"})
So I need some way to tell boot-cljs to make the output dir and output-to match the asset-path.
@samestep thank you very much, that helped!
so I have an ip address which build.boot knows , but I don't want to ahrd code into a cljs file -- I want build.boot , when it calls cljs-repl or cljs, to somethow pass this info as an argument
@qqq there are two options to do that. One is to use :closure-defines
(a cljs compiler option) the other is to use a macro that reads the value from boot.user
or from an env var
@martinklepsch : so my laptop ahs a dynamic ip, so build.boot ahs a function (get-ip) opt1 = pass it via :closure-defines ... (get-ip) opt2 = put get-ip in a *.clj file as a macro, then have cljs expand it at compile time? clever; thanks!
@martinklepsch : apparently this blogger is #4 on google for "closure defines boot" https://www.martinklepsch.org/posts/parameterizing-clojurescript-builds.html
should be #1 😛
it doesn’t have to do anything with lein or boot really. :closure-defines
is a compiler option that you can pass to boot-cljs via :compiler-options
okay, so one of my tasks becomes:
(comp
(watch)
...
(cljs :compiler-options {:closure-defines {'foo "some-constant"}))
?that seems about right
Fixed the wiki. :closure-defines currently only work under a compilation mode, i.e. a higher setting than :none.
https://groups.google.com/forum/#!topic/clojurescript/7wAO_GzsITM
gah@martinklepsch : it all works now! I forgot the goog-define, which is important to trigger a @define; thanks for all your help at this weird hour
> Fixed the wiki. :closure-defines currently only work under a compilation mode, i.e. a higher setting than :none.
That is old and it should work with :none
@qqq it’s approaching 6pm where I am so you’re welcome 😛
yeah, it works now, wiki apparently is out dated, and the problem is I was missing the goog-define
I’ve got a patch for boot-cljs enabling user-defined :output-dir
and :output-to
. I know this comes up occasionally, so before I file an issue and submit a PR I’d like to know what the outcome of those discussions was. In particular, is there some reason to not support this? Thx.
Well, I'm not completely happy about the current status because of problems with asset-path etc, so I might accept this
But my opinion still is that the .cljs.edn file is good practice
First, it allows changing the configuration without restarting the build process
And at least in theory, the file path should allow automatically setting several options, in addition to Cljs :output-dir
and :output-to
, boot-reload also uses it
Here’s an example:
{:require [miraj.demo.greetings.greetings-hello.core],
:init-fns [],
:compiler-options {:optimizations :none,
:asset-path "/miraj/demo/greetings",
:output-dir "miraj/demo/greetings",
:output-to "miraj/demo/greetings/greetings_hello.js"}}
This allows me to jar up my code and use it on any webpage by just :require
-ing it. My index.html has
<script src="/miraj/demo/greetings/greetings_hello.js"></script>
Probably that would also work without .cljs.edn file as in that case the .cljs.edn is created using task options
Hmm, yeah, why not? I haven’t added cmd line options but that should work as well. It’s really just path manipulation.
Doesn't need new task options, compiler-options
is already one option so these can be provided through that
Yeah, I'm open to this change, seems like good idea to allow overwriting any compiler-options, but defaulting to Boot-cljs values
I hope to allow the same with :main
option
see the outputs-fix branch at https://github.com/mobileink/boot-cljs/tree/outputs-fix
yeah, mostly just change to main
to only set the options if they don't already have values
re: boot port to dotnet and nuget repositories One of the daunting issues is re-implementing POD without class loaders. I did a look through the boot source and the only place I found that used make-pod was the aot task. That seems to imply that I could do a first pass without POD? Am I missing something?
yeah, the pods boot uses are started in java, in https://github.com/boot-clj/boot/blob/master/boot/base/src/main/java/boot/App.java
most of the dependencies used by the builtin tasks are run in the 'worker pod' which is started there
in https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj you can search for eg pod/with-call-worker
to see uses of the worker pod
@alandipert thanks
of course, many of these tasks are doing things that are maybe irrelevant in c#. but the basic idea is to keep the dependencies of tasks out of userspace
is there any way to get boot-reload or similar to reload javascript? my clojurescript is already compiled by the time i need a reload - its in a checkout jar.
my understanding is that the reload task will reload the clojurescript, not the javascript?
first thing to check is whether the js file is being sent to the cilent via the websocket
let's say i have javascript in my sources, not clojurescript. would reload do anything with it?
ok, i misunderstood reload. sounds like its already what i need. (sorry, not at my machine atm.)
but the readme says the reload task must precede the cljs task. shouldn't it be the other way round?
reload needs to inject some code into the cljs build, which is the reason for that ordering
wait. the following cljs task changes the js, which triggers the watch task again, so the next reload picks it up? and the next cljs does not change anything, so the loop exits?
I think that's close, but it's more like - a file change triggers watch, which re-runs reload, which sends a signal over the websocket to tell the frontend to refresh certain files
yeah, but if i only changed my cljs, and task cljs has not yet run, there is no change in the js files to pick up, no?
well, you can think of it that way, but any boot task can do stuff before the rest of the chain runs, or after
so, in real code: https://github.com/adzerk-oss/boot-reload/blob/master/src/adzerk/boot_reload.clj#L162
the stuff before that line happens before the rest of the chain has run, and the stuff after it happens after the rest of the chain has run
Boot uses middleware pattern just like Ring
yes, that's what I was referring to. those macros are just convenience wrappers that implement partial middleware patterns
of course. i keep forgetting about that, never saw a reason to use it. boot-reload is a great use case.
heh, I guess it doesn't seem so fiendish if you've been using middleware for a long time 🙂
that's another one of those conceptual hurdles. i generally think of the pipeline as one-way, but it's actually two-way. or rather it's a pair of pipelines running in opposite directions.
this is the first time i've come across a case where doing sth "on the way back" makes sense. got any other cases?
hmm, I think all of my personal stuff uses with-pre-wrap
, or the non-macro equivalent... I would assume that's how most tasks work
does boot support running pipelines in parallel?
not without trickery, I don't think
for example, our project has UI and backend builds that could happen concurrently. Just wondering if it was possible to do in parallel without multiple JVM instances
@cpmcdaniel there is a boot.parallel
ns to try out and report me, I think you could be the first one who uses it 🙂
It is a namespace in boot so you can just require
it. an example usage is boot.test
.
sounds like a nice holiday project