This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
I’m trying to get boot-cljs to work by following the steps in the readme but so far no luck https://gist.github.com/kardan/41f9d5a7388368792330. Any hints on what I’m doing wrong?
i tried recently to give clj-refactor a try but looks like it’s closely tied with leiningen and its project.clj. function cljr-add-project-dependency
for example does not work at all. I tried to ask maintainers for a help but seems that this is boot architecture which makes it hard to reuse with clj-refactor. could you take a look at https://github.com/clojure-emacs/clj-refactor.el/issues/238 and briefly enlighten me what’s the story behind classpath- vs realpath-based file locations?
@kardan: you need to add clojurescript as a dependency
Getting this sometimes with boot-cljs and boot-reload:
Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened.
@lukemorton: can you paste the full stacktrace? (or a screenshot of it)
Just referenced my browser will do next time it occurs
refreshed*
https://www.dropbox.com/s/7ssyjxvfpgj155t/Screenshot%202015-09-26%2012.03.33.png?dl=0
hm, so there’s no actual stacktrace
indeed
@lukemorton: what files are being reloaded?
safe.js links to: https://www.dropbox.com/s/sp19xb8gn7gj41r/Screenshot%202015-09-26%2012.05.05.png?dl=0
@martinklepsch: ha, missed that 😇 thanks
@kardan: no problem! if you’re starting a new cljs project you might also want to checkout tenzing: https://github.com/martinklepsch/tenzing
tenzing is awesome stripped it down a little but the thing Im working on is based on it
cool, will have a look. I’m just started with the client side of things & have not really used cljs much
@lukemorton: what did you strip away?
Simplified the build.boot tasks to my needs
@lukemorton: re your issue I’d check the reloaded files for documentWrite calls and trace that to your code
also I haven't kept the boot.properties file, not sure the need for it
and I haven't got src/cljs, just src/my_namespace
@lukemorton: it’s to pin boot version and specify a clojure version to use
you don’t always need it but it’s “safer"
gotcha
will add back, oh and I put sass in resources
@lukemorton: why? if you put it in resources it will be part of the build?
ah thats why I see Compiling sass/app.scss Compiling app.scss
what does "resources" mean? I figured it was assets like .sass and .html
yes, but .sass
isn’t yet a “resource” because you compile it to css first, then this css file could be considered a “resource"
gotcha
Coming to clojurescript new, the messy chestnut project.clj and weird env/dev/ files was just a bit much. Found boot and tenzing easier to work with especially given a small bit of experience with gulp and ring
@mathiasx: boot-sassc doesn't compile when an @import'd file changes, is this expected?
@lukemorton: does the imported file start with an _
?
@martinklepsch: Boot-sass should now support .sass files
@lukemorton: try with a prepended underscore, I think sass has some rule about imported things needing to start with an underscore
You were right about the underscore! Too used to sprockets
@juhoteperi: cool. Just tried and failed because the sass4clj dep is outdated I guess.
Ah forgot to deploy that one parhaps
should be deployed now
how do I updated an already downloaded snapshot?
umh, one way would be to remove it from m2
Maven will sometimes chek for new versions
boot show -U
just worked for me
Aargh, ws-host pr broke it
@martinklepsch: Have you looked into boot-cljs exception handling?
I'll look into it
Oh right.... if we rethrow the errors we have no way to pass the message forward like we currently do
oh. that makes sense.
Looks like it's best to rethrow all exceptions from boot-cljs and handle them in boot-reload
and then rethrow them again for other tasks?
And the exceptions from cljs compiler are wrapped in ExecutionException when boot-reload sees them
Very strange. Boot will print the correct exception data but I can't seem to access that from boot-reload.
Ah no...
Now I see it
The data is only on concurrent.ExcecutionException message 😞
I wonder if that's from parallel stuff in boot-cljs or from pods
@micha: How do exceptions work with pods?
I'm trying to handle boot-cljs exceptions in boot-reload
But the exceptions lose the ex-data somewhere
If I understand pods, everything goes to pods through pr-str and comes out through read-string
But I don't see how that would work at all for exceptions
One solution would be to catch all exceptions in boot-cljs impl, return data and then throw new exceptions in boot-cljs
the ex-data issue is due to clojure objects not being resolvable in other clojure runtimes
could this be handled more easily if we’d not use pr-str for passing things between pods?
passing tmpfiles is also something that feels like it should work
i think what we'd have to do is create an exception class in java in the boot java code
I don't see how you could support all exceptions classes
Taking first steps with cljs, and are stumbling a bit. If I don’t use “serve” to run my app. How do I "get to” the target/main.js file? Anyway to pipe things to a dir like resources/public/js ? Or is it time to learn the classpath properly 🙀
@juhoteperi: the fileset seems to be the best place for the error stuff, perhaps
@micha: The first idea was to catch exceptions in boot-cljs side and have boot-reload read them from fileset
but e.g. speak
is waiting to catch exceptions
@micha @juhoteperi is there no way to serialize exceptions in java?
couldn’t pods just catch all exceptions and “send them back” ?
Hmmh right, boot-cljs could write to the file inside pod
@micha I’m just trying to compile cljs and host it in my clojure web app But I think I confuse myself
@micha: tmpfile metadata would need to be set outside the pod
and I can't access the exception data outside the pod, even in boot-cljs
But then it's the same just to throw it
To return anything from impl, I have to catch all exceptions
the classpath is the core of JVM programming, so i recommend getting a basic understanding of it
the problem the classpath solves is how to access parts of the program that aren't in memory
like applications, if they're at all complex, will have parts of them in files on disk, in compressed archives, etc
or you may have a web server program (like http-kit, ring, etc) that will be serving resources
so for example when you do (require 'foo.bar)
in clojure, clojure knows it needs to look for a resource named foo/bar.clj
I always just thought of it as the path in the terminal (but that might be to simplistic)
Hah, I think I found way to even get original stacktraces from cljs exceptions
by manually serializing and deserializing them
It keeps the original stacktrace and cause stack
clojure map
ex-data could have something which can't be printed 😕
well unreadablöe
cljs compiler puts file objects to ex-info sometimes
or well, pretty much always
Luckily it's probably only thing that causes problems
I just walk the ex-data and convert Files to strings
I wonder if tasks should have a way to mark exceptions so that boot won't print stack trace for them?
Then boot-cljs could display simple warnings itself and rethrow exceptions for other tasks
But user has no need to see the horribly long stacktrace
I think they should still be exceptions
Other tasks can't go forward if exception happened during cljs compilation
Perhaps
"Stack trace of root exception is empty; this is likely due to a JVM optimization that can be disabled with -XX:-OmitStackTraceInFastThrow." 😄
Also, it will still print ex-data because I need that for boot-reload
Perhaps I'll provide another task with boot-cljs which can be used as last part of pipeline
Do java loggers allow that?
I have only seen option to either print or not print the stack trace
And not per logger class?
Perhaps it'd be possible to write custom Layout class which checks message logger and logs stack trace based on that...
But doubt that would be best solution
For now, I think I'll just let it print full execptions on console
With minor polishing, e.g. I can catch all ExecutionException and rethrow their causes to remove one layer of cause stack
I think I finally found quite good and simple solution
Boot-cljs will "modify" existing Cljs exception instead of wrapping it in another exception-info. Mostly it will replace file-path which points to temp-dir with one that points to original source-path.
And boot-reload will show all exceptions, cljs exceptions just happen to have line number etc. on ex-data.
Did you already check the boot-cljs code? 😄
Mostly the added code is for serializing and deserializing exceptions (and tests for it)
Other than that, the changes are quite small
Now boot-reload only misses feature to reconnect to the server after Boot is closed and reopened
That would be last feature we are missing in comparison to Figwheel, I think