This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-05
Channels
- # beginners (46)
- # calva (89)
- # cider (24)
- # clara (7)
- # clj-kondo (36)
- # clojure (33)
- # clojure-australia (4)
- # clojure-dev (9)
- # clojure-europe (15)
- # clojure-israel (1)
- # clojure-nl (1)
- # clojure-uk (13)
- # clojurescript (55)
- # community-development (38)
- # conjure (1)
- # cryogen (12)
- # cursive (16)
- # data-science (4)
- # datomic (39)
- # events (2)
- # fulcro (5)
- # gorilla (3)
- # introduce-yourself (3)
- # jobs (9)
- # kaocha (5)
- # malli (16)
- # music (12)
- # off-topic (11)
- # polylith (4)
- # react (4)
- # reactive (1)
- # reagent (18)
- # remote-jobs (2)
- # reveal (2)
- # sci (4)
- # shadow-cljs (31)
- # timbre (4)
- # tools-build (70)
- # tools-deps (11)
- # vim (33)
- # xtdb (53)
@leif you need to change the deps.edn
in tools.reader. it doesn't include the src/main/cljs
path https://github.com/clojure/tools.reader/blob/master/deps.edn#L2
Hi There, Is there anyways we can read the content of html in ClojureScript ? For Example: I have example.html file. I want to create a function in clojurescript that would take the file as an argument.
@singhamritpal49 Are you in the browser or in Node.js?
Or you can inline the HTML at build time using a macro (this is probably not what you want with HTML but there may be a use case for it)
Have an <input type="file">
somewhere, use it to let the main web page access that HTML file. No other way since browsers do not allow web pages to access random local files.
@thheller Thanks. So then if it wasn't in the classpath in the first place, why does it normally work with clojurescript?
when you use the tools.reader release normally the bundled jar contains all the required cljs files. deps.edn isn't used to create that, don't know why its missing there
its included here https://github.com/clojure/tools.reader/blob/master/pom.xml#L14-L17
(I also don't really understand what pom.xml
is for. It almost looks like its used for maven, but ya.)
tools.reader is much older than deps.edn so nobody switched deployment over yet I guess. no need to change a working solution too š
Hmm...so, by adding src/main/cljs
to the tools.reader
classpath it does build, but still seems to be using the old tools.reader
library.
(Here is the tools.reader
deps.edn file btw:
{:deps {org.clojure/clojure {:mvn/version "1.10.3"}}
:paths ["src/main/clojure" "src/main/cljs"]}
)there is no clojurescript dependency? are you using the clojure variant but made changes to the cljs variant?
if you use the standard clojurescript jar that'll contain a AOT compiled variant of the clojure parts
Its basically the latest version of clojurescript but with a few extra hooks added that makes sandboxing in self-hosted cljs.js
possible.
@thheller I should ask, does closurescript use the pom
file, the deps.edn
file, or the project.clj
file for deps management?
(It almost looks like its deps.edn
and the other two are around for legacy purposes, but I'm not 100% sure.)
ClojureScript itself builds with script/build, which then primarily uses maven to build from the pom.xml
I'm not sure what you're actually trying to do but using ClojureScript as a git dep is unlikely to work very well
@alexmiller Oh interesting. I've..err..actually been doing it for the past 6 months or so without any problems I've noticed. I wonder if there's problems that I haven't noticed yet.
Well, maybe Iām out of the loop on it
(For reference, what I want is mostly to be able to dynamically set the core, so I can use that to have the eval-fn
run in a sandbox.
Curious if any CLJS tooling out there has an answer for Node REPLs crashing on exceptions. More specifically, when you're trying to run unit tests in the REPL. We're migrating some tests off promise chaining to leverage core.async
instead.
The best we could come up with is something like this in a dev profile.
(defn exception-handler [err] (println err))
(defn handle-all []
(.on js/process "uncaughtException" exception-handler))
(defn handle-none []
(.removeListener js/process "uncaughtException" exception-handler))
Which might be good enough, but the NodeJS API says any handler attached for uncaughtException
should also exit the process.
Not sure what kind of garbage or bad state we'd be accumulating if we did that.
Current toolchain:
[org.clojure/clojure "1.10.1"]
[org.clojure/clojurescript "1.10.879"]
[org.clojure/core.async "1.3.618"]
[lein-cljsbuild "1.1.7"]
[lein-figwheel "0.5.20"]
[cider/piggieback "0.5.2"]
[figwheel-sidecar "0.5.20"]
[lein-doo "0.1.10"]
I suspect this isn't a "tools" thing and just the behavior you get by using Node, but curious what others have done. Or if they just deal with the REPL dying.
I use forever or something similar to restart node on crash š
You still need to reload all your Clojure source though, correct?
I use shadow-cljs, but yeah I guess bode would reload the script all the time. Unless you make a try catch inside your main function and then do repl dev in the side.
I'm not entirely sure what you mean by "REPL dev in the side" but I don't think a try catch in main would work for asynchronous errors bubbling up during tests. By that point, you're no longer inside the try catch. Unless you intercept the Node exception handler, I think you're stuck reloading the REPL / sources or using something that does it for you.That really hurts iteration, especially if it happens a few times and you have a lot of sources to load.