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?
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.
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: re your issue I’d check the reloaded files for documentWrite calls and trace that to your code
.sass isn’t yet a “resource” because you compile it to css first, then this css file could be considered a “resource"
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: try with a prepended underscore, I think sass has some rule about imported things needing to start with an underscore
@juhoteperi: cool. Just tried and failed because the sass4clj dep is outdated I guess.
Oh right.... if we rethrow the errors we have no way to pass the message forward like we currently do
Looks like it's best to rethrow all exceptions from boot-cljs and handle them in boot-reload
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.
If I understand pods, everything goes to pods through pr-str and comes out through read-string
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?
i think what we'd have to do is create an exception class in java in the boot java code
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 🙀
@micha: The first idea was to catch exceptions in boot-cljs side and have boot-reload read them from fileset
@micha I’m just trying to compile cljs and host it in my clojure web app But I think I confuse myself
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
I always just thought of it as the path in the terminal (but that might be to simplistic)
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
"Stack trace of root exception is empty; this is likely due to a JVM optimization that can be disabled with -XX:-OmitStackTraceInFastThrow." 😄
Perhaps I'll provide another task with boot-cljs which can be used as last part of pipeline
Perhaps it'd be possible to write custom Layout class which checks message logger and logs stack trace based on that...
With minor polishing, e.g. I can catch all ExecutionException and rethrow their causes to remove one layer of cause stack
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.
Mostly the added code is for serializing and deserializing exceptions (and tests for it)
Now boot-reload only misses feature to reconnect to the server after Boot is closed and reopened