This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-25
Channels
- # 100-days-of-code (6)
- # announcements (4)
- # aws (2)
- # beginners (151)
- # boot (1)
- # calva (1)
- # cider (19)
- # clara (47)
- # cljdoc (9)
- # cljs-dev (25)
- # clojars (18)
- # clojure (151)
- # clojure-canada (1)
- # clojure-conj (1)
- # clojure-dev (17)
- # clojure-italy (42)
- # clojure-nl (34)
- # clojure-spec (67)
- # clojure-uk (125)
- # clojurescript (163)
- # core-async (106)
- # cursive (19)
- # data-science (11)
- # datomic (9)
- # duct (2)
- # figwheel (1)
- # figwheel-main (6)
- # fulcro (97)
- # graphql (9)
- # instaparse (4)
- # jobs (6)
- # jobs-discuss (21)
- # leiningen (62)
- # mount (23)
- # off-topic (16)
- # re-frame (15)
- # reagent (16)
- # reitit (5)
- # remote-jobs (1)
- # ring-swagger (9)
- # shadow-cljs (176)
- # tools-deps (102)
- # unrepl (3)
what's the advantage or disadvantage of using shadow's built in nrepl vs cider-nrepl (when using cider)?
@vigilancetech that is a question for the cider folks. its all about their middleware and what features it provides. I think it provides auto complete and other things but I'm not sure what.
I might be missing something, however when trying to load modules on demand using shadow.loader
in dev, it seems to 404 since it’s making the request for the additional compiled JS files to the port that the actual application is running in (5000), and not the port that the shadow dev server is serving the JS files from (3449). I have {:devtools {:loader-mode :eval :http-port 3449 :http-root "resources/public"}}
set in the associated build, is there anything else I might be missing?
@koz its just a static file request on the same server that also served the initial .js file
Also, is :loader-mode :eval
still a valid flag? I think at one time it was used to opt-in to a new loading mode, but can’t find any mention of it in the docs.
oh right if you use that it may have problems with shadow.loader depending on the version you are on
forgot which version I fixed that in but it was some time after I added loader-mode :eval
Just updated to 2.6.18
and still running into the same issue. The app has a script tag to load the main JS bundle from the shadow dev server (http://localhost:3449/js/compiled/dev/main.js), which is working fine. Are you saying that any modules loaded via shadow.loader
(e.g. /js/compiled/dev/cljs-runtime/lazily_loaded_module.js
) won’t load from that same localhost:3449
, but that our application server (instead of the shadow-cljs devtools server) needs to be configured to statically serve the compiled JS bundles?
typically thats just a path so it would request relative to the location of the current document
that worked, however I’m getting CORS errors from accessing a resource on a different port via XHR. I tried adding
{:devtools {:push-state/headers {"content-type" "text/html; charset=utf-8"
"access-control-allow-origin" "*"}
to my shadow-cljs.edn, but don’t see the second header.the push-state handler is only for actual push-state requests (ie. files that don't exist)
i see. yeah it would take a bit of extra configuration on our end, but we can make something work for now. thanks!
hello, sometimes I'm getting this in my CI release build for shadow:
aborted par-compile, [:shadow.build.classpath/resource "garden/compiler.cljc"] still waiting for #{garden.units}
{:aborted [:shadow.build.classpath/resource "garden/compiler.cljc"], :pending #{garden.units}}
ExceptionInfo: aborted par-compile, [:shadow.build.classpath/resource "garden/compiler.cljc"] still waiting for #{garden.units}
clojure.core/ex-info (core.clj:4739)
clojure.core/ex-info (core.clj:4739)
the ns after still wanting for
usually changes, so I'm wondering if that's some shadow timeout? if it is, can I increase it somehow? as the codebase grows I'm feeling its starting to happen more often, a second trigger of the build usually works
@wilkerlucio hmm do you have a verbose log? the timeout is 60000 already and its very unusual if it hits that? you can increase is via :build-options {:par-timeout <num-in-ms>}
@wilkerlucio I was running into a similar issue on CI as well.
I was running a number of release builds concurrently, and switching to running them synchronously seems to have resolved the issue
this is so weird logically. the tasks are submitted in dependency order so it is ensured that garden.units
is compiled before garden.compiler
.
so the only case where garden.compiler
is even waiting for compile is when a thread is becoming available while the others are still compiling
garden.units
should never take this long to complete and it must have started no matter how many other jobs there are
a verbose log should at least end with the time it took for garden.units
to complete
@thheller a lot of times I get this with cljs.core
as well, and I'm running 2 parallel builds, the total compilation time gets to about 6 minutes when it works
just a lot of files, 70K CLJS lines without counting deps, 😛
@thheller I'm having an issue that I had before with release builds regarding externs on .js
files, but I can't remember how I fixed that, is that a way to tell the compilation to dont mangle code from .js files?
it doesn't matter how many files there are. the queuing ensures that they are compiled in proper order with minimzed wait times
@wilkerlucio shadow-cljs check the-build
should tell you
i'll definitely add the sequential option so that release
builds don't run in parallel by default
is there a way to run shadow using a diferent profile then the one defined on shadow-cljs.edn
?
Ok so I've figured a nice way to generate bindings for Wasm modules. I'm a shadow-cljs noob. Where do I start to work out a packaging solution
Theres an array buffer that must be loaded async, and functions defined afterward. Would be nice to treat it as a module
yes talking linking up to exported functions ourselves. I think I've got it but next step after is the important bit
instead of doing this https://github.com/pkpkpk/fress/blob/master/src/wasm_test/fress/wasm_test.cljs#L68
right now you have to use a string to lookup the exported function and use that to call it
you get your array buffer, separately a description of the module, and generate cljs bindings from that
so what I ideally want is a .wasm
file and a .json
or .edn
file that has some data about the file
build details are less interesting, getting async needs of namespaces etc is where I need help
that too but is poorly supported. Im looking for easy integration with cljs project minus dealing with this stuff.
which stuff? its like 3 lines of code? the complicated part as I see it is passing function INTO the wasm so it can call js functions
Yes it would be nice to distrubute wasm modules as libs is all. I agree the existing burden is really all that bad
I was asking you to write something, I'm offering a contribution. but if you just want the raw tools thats cool
yeah I totally want to explore how I can integrate .wasm
into shadow-cljs to make things nicer
I am saying, we can have a binary and a description, and turn it into something that feels like a namespace
the process of packaging that up should inform how the description is used with the binary
The one from me does work, and since you only need to use it by calling the functions in the JavaScript that comes with it, there is no need to do anything to the wasm at compile time, besides copying it.
Apparently there was a pr for adding wasm to externs for closure, but it wasn't accepted. https://github.com/google/closure-compiler/pull/2534
https://github.com/google/closure-compiler/blob/master/contrib/externs/webassembly.js ?
yes the one you have works .. unless you modify or rewrite the JS in any way then it doesn;t
@thheller sorry, wasn't clear, I mean lein profiles, because I have a specific type of run that I want to have different deps there
@wilkerlucio no thats not supported but you can just use lein with-profiles +whatever run -m shadow.cljs.devtools.cli release whatever
@lilactown @wilkerlucio on your failing builds. how many CPU cores do the machine have? 1-2?
5 ~ 6 min here, I don't how many cpus are on this one, I can check, but those are shared instances doing CI for a lot of projects
I know in erlang processes only get a certain number of reductions but I think thats different on the JVM
probably the only area where parallel build is useful to begin with is running multiple closure optimizations in parallel