Fork me on GitHub
#clojurescript
<
2021-10-05
>
thheller06:10:12

@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

thheller06:10:28

so the sources won't be on the classpath

fsd13:10:00

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.

borkdude14:10:35

@singhamritpal49 Are you in the browser or in Node.js?

borkdude14:10:56

In the browser you can do an HTTP request to your server to fetch the HTML

fsd14:10:07

Browser

borkdude14:10:35

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)

fsd14:10:36

File is locally stored

p-himik14:10:33

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.

borkdude14:10:51

Ah so the user should upload a local file. Now I get it :)

leif19:10:12

@thheller Thanks. So then if it wasn't in the classpath in the first place, why does it normally work with clojurescript?

thheller19:10:33

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

leif19:10:06

AH, okay

leif19:10:10

That makes sense.

leif19:10:52

Okay, I'll give it a shot, thanks. šŸ™‚

leif19:10:07

(I also don't really understand what pom.xml is for. It almost looks like its used for maven, but ya.)

leif19:10:24

Or rather, why tools.reader uses it instead of just deps.edn.

thheller19:10:00

tools.reader uses maven to create and publish the jar files

thheller19:10:40

tools.reader is much older than deps.edn so nobody switched deployment over yet I guess. no need to change a working solution too šŸ˜›

leif19:10:29

Makes sense. šŸ™‚

leif19:10:06

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.

leif19:10:26

(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"]}
)

thheller19:10:15

there is no clojurescript dependency? are you using the clojure variant but made changes to the cljs variant?

thheller19:10:51

ah nvm. what clojurescript version do you have in your project?

leif19:10:08

Its..err...a custom version, here:

thheller19:10:09

if you use the standard clojurescript jar that'll contain a AOT compiled variant of the clojure parts

leif20:10:04

Its basically the latest version of clojurescript but with a few extra hooks added that makes sandboxing in self-hosted cljs.js possible.

thheller20:10:01

so in your project you are using that as a git dep or local/root?

leif20:10:17

Here is the project's deps.edn file

leif20:10:08

(Well, except for the line that replaces tools.reader on my local machine

thheller20:10:16

should be fine

leif20:10:38

@thheller I should ask, does closurescript use the pom file, the deps.edn file, or the project.clj file for deps management?

leif20:10:22

(It almost looks like its deps.edn and the other two are around for legacy purposes, but I'm not 100% sure.)

Alex Miller (Clojure team)20:10:10

ClojureScript itself builds with script/build, which then primarily uses maven to build from the pom.xml

Alex Miller (Clojure team)20:10:37

I'm not sure what you're actually trying to do but using ClojureScript as a git dep is unlikely to work very well

leif23:10:12

@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.

Alex Miller (Clojure team)23:10:29

Well, maybe Iā€™m out of the loop on it

leif23:10:44

(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.

leif23:10:03

(And by sandbox, I 'mostly' just mean stopify.)

leif23:10:22

Ah, fair enough. FWIW, I was also kind of surprised that it worked. šŸ™‚

Steven Lombardi23:10:35

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.

Steven Lombardi23:10:00

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))

Steven Lombardi23:10:40

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.

Steven Lombardi00:10:45

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"]

Steven Lombardi00:10:37

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.

David Pham07:10:08

I use forever or something similar to restart node on crash šŸ™‚

Steven Lombardi19:10:37

You still need to reload all your Clojure source though, correct?

David Pham12:10:58

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.

Steven Lombardi17:10:47

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.