Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-08-06

Channels

#clojurescript
<
2020-08-06
>
zackteo00:08:06

@noisesmith Sorry I'm not actually sure how pulling a "helper" namespace in js modules might work :thinking_face: Like how might I run the js code base with some cljs? With clojurescript tools?

noisesmith00:08:15

the clojurescript compiler takes cljs source code, and creates js code, your js files can use those the same as they'd use other external js deps

dnolen00:08:15

@zackteo there's actually a lot of ways to do that, and no it doesn't need to be all at once

dnolen00:08:54

ClojureScript is designed to work with JavaScript, and now even w/ JS bundlers

dnolen00:08:10

it might help to know what your JS app looks like and then it will be easier to say which route you should take

dnolen00:08:22

i.e. React SPA, something else?

zackteo00:08:29

The code base im thinking of is a GIS web app. Running with React, Leaflet (can't quite recall if there's any more similarly big dependencies)

dnolen00:08:35

do you use Webpack to build it, something else?

zackteo00:08:30

Yeap webpack!

dnolen00:08:57

this is a good starting point

dnolen00:08:17

at this point it doesn't really matter what tool you use shadow-cljs, Figwheel - it's mostly a matter of taste

dnolen00:08:33

It might take a little bit of work to get it setup depending on how your app works, but fundamentally ClojureScript is designed to do what you want

dnolen00:08:41

work with existing JS and write ClojureScript

dnolen00:08:32

shadow-cljs probably has the most affordances if you're coming from JS and looking for a fast on board

dnolen00:08:52

but plain ClojureScript and Figwheel are certainly capable of accomplishing more or less the same thing

zackteo00:08:00

Got it! Thanks for your help!! Didn't know there was such a guide - but probably cause I didnt think to search from webpack

zackteo00:08:21

I see I see, I'm just generally trying to entertain the possibility of introducing ClojureScript to a company I was interning at cause I genuinely felt a lot of their pain points could be eased with ClojureScript.

zackteo00:08:07

Not that the 1 year to be fresh grad me, would easily be able to make such a seemingly drastic change unless quite miraculously. But am exploring my options as I hope to be able to start my career with Clojure/(Script) somehow

noisesmith00:08:28

yeah, I interpreted your question too literally - you can take an existing js code base and add new cljs code, and use both together

zackteo00:08:58

Doesn't help that I'm in Singapore atm with pretty much no Clojure/(Script) being used anywhere - or at least based on what I know - companies too risk adverse :man-shrugging:

reefersleep09:08:22

A while ago, I read a post on something like Clojureverse or r/Clojure about Chrome discontinuing support for whatever makes Dirac DevTools tick. I can’t find it again. Did I just dream it?

darwin09:08:08

no, it was related to cljs-devtools (Custom Formatters feature in Chrome DevTools)

darwin09:08:30

they wanted to remove support for it because of security concerns

darwin10:08:25

but decided to keep it the way it is for now, thanks to twitter response of affected cljs users

reefersleep10:08:19

@U08E3BBST I’ve decided to try Dirac again. I’m using the command line tool to start up Chromium, and navigating to localhost:3449 , the address of my application. However, I’m getting 

Version mismatch: Dirac Runtime installed in your app has different version (v1.6.1) than Dirac Chrome Extension (v1.6.0).
To avoid compatibility issues, please upgrade all Dirac components to the same version: .
on Dirac initialization, along with a bunch of errors like 
core.cljs:322 Uncaught Error: No protocol method ISwap.-swap! defined for type cljs.core/Atom: [object Object]
from my application. Do you have a hunch about what I could be doing wrong?

reefersleep10:08:41

I tried with two different applications, and the result seems to be the same.

reefersleep10:08:08

I forced use of 1.6.1 after seeing the error by adding and sourcing the env var export DIRAC_CLI_VERSION=1.6.1 dirac

reefersleep10:08:56

Which dirac seems to react on - the version stated in the terminal on initializing dirac is now 1.6.1, where it was 1.6.0 before, but the error message in the browser seems to be the same.

reefersleep10:08:02

I just installed the dirac CLI, so I don’t understand the incompatability errors. I depended on binaryage/devtools in one of the projects I tried, but removed the dependency, and it made no difference.

darwin17:08:45

@U0AQ3HP9U “Dirac Runtime” is a library you are using in your app, you should bump deps in your app

reefersleep19:08:31

@U08E3BBST I had misunderstood. I thought that just installing and running Chromium with the CLI would be sufficient.

reefersleep19:08:44

Wow, it’s very involved. And I won’t even be able to use it with the project I intended, since that already uses piggieback middleware.

darwin19:08:11

you need that integration just for REPL

darwin19:08:27

other features should work without it

darwin19:08:06

why do you want to use Dirac?

reefersleep19:08:33

I just want to see how it can help me 🙂

darwin19:08:49

likely not much, Dirac helps in advanced scenarios when you want to step through cljs code in devtools a maybe eval some cljs code at breakpoints

darwin19:08:06

other than that, all just nice-to-have features

reefersleep19:08:26

It wasn’t obvious to me that the part was optional.

darwin19:08:27

like friendly names in call stacks and scope section

reefersleep19:08:02

Hm, well. Maybe I’ve been missing that eval feature more than I knew. 🙂

reefersleep19:08:44

But I’m still getting the same errors, after having included the dependencies with the correct versions.

darwin19:08:21

the message above said that you have 1.6.1 in your app but the extension was 1.6.0 to me it looks like your chrome canary is not the latest, so the CLI picked dirac 1.6.0 not 1.6.1

darwin19:08:51

here is the mapping between chrome versions and dirac versions https://github.com/binaryage/dirac/blob/master/releases.edn

darwin19:08:26

anyways you might want to ignore that warning, there were no changes in dirac runtime between those two versions

reefersleep19:08:23

Hm, ok. I installed Chromium today with brew cask, perhaps that’s not the newest version.

darwin19:08:48

show me what dirac cli prints on startup

reefersleep19:08:01

But regardless of that warning being irrelevant, I’m still getting errors like 

http_client.cljs:25 Uncaught Error: No protocol method ISwap.-swap! defined for type cljs.core/Atom

darwin19:08:36

no idea, AFAICT, ISwap normally is defined for Atom

reefersleep19:08:44

doe@Srens-MacBook-Pro-2 ~ $ dirac
Located Chromium executable at '/usr/local/Caskroom/chromium/793929/chromium.wrapper.sh'.
Detected Chromium version '86.0.4220.0'
Resolved matching Dirac release as '1.6.0'
Matching Dirac release is located at '/Users/doe/.dirac/silo/v/1.6.0'
Preparing playground environment at '/Users/doe/.dirac/playground'
Compiling playground project...
Starting playground HTTP server on port 9112
Booting Dirac Agent...
Starting nREPL server v0.8.0 on port 36180
-----------------------------------------------------------------------------------------------------------
WARNING!
We detected unexpected tools.nrepl library version in your nREPL server at !
The server reported version 0.8.0, but Dirac expected version 0.7.0.
This could potentially lead to unexpected behaviour. Please check your dependencies and use latest Dirac release.

For reference, the reported versions by the nREPL server are:
{:clojure "1.9.0", :java "1.8.0_92", :nrepl "0.8.0"}

Also double check Dirac installation instructions: .
-----------------------------------------------------------------------------------------------------------
Dirac Agent v1.6.1
Connected to nREPL server at .
Agent is accepting connections at .
Launching Chromium [with --user-data-dir='/Users/doe/.dirac/chromium/profiles/default'] ...
[51968:775:0806/214551.159883:ERROR:(208)] [21:45:51.146] FIDO:  Touch ID authenticator unavailable because keychain-access-group entitlement is missing or incorrect

darwin19:08:40

for Dirac 1.6.1 to be selected, Chromium version must be 86.0.4221 or greater

darwin19:08:01

so you should be using 1.6.0 runtime with your chromium

reefersleep19:08:48

I’ll try that.

darwin19:08:29

in general I would not recommend cask for Canary, it self-updates so there is no need to have it managed by brew

reefersleep19:08:03

Aha. Well, I just like installing everything with brew - it fits better in my head that way, rather than a sprawl of different install methods.

reefersleep19:08:50

This looks a bit better: 

doe@Srens-MacBook-Pro-2 ~ $ dirac
Downloading: binaryage/dirac/1.6.0/dirac-1.6.0.pom from 
Downloading: org/clojure/core.async/1.2.603/core.async-1.2.603.pom from 
Downloading: nrepl/nrepl/0.7.0/nrepl-0.7.0.pom from 
Downloading: nrepl/nrepl/0.7.0/nrepl-0.7.0.jar from 
Downloading: binaryage/dirac/1.6.0/dirac-1.6.0.jar from 
Downloading: org/clojure/core.async/1.2.603/core.async-1.2.603.jar from 
Located Chromium executable at '/usr/local/Caskroom/chromium/793929/chromium.wrapper.sh'.
Detected Chromium version '86.0.4220.0'
Resolved matching Dirac release as '1.6.0'
Matching Dirac release is located at '/Users/doe/.dirac/silo/v/1.6.0'
Preparing playground environment at '/Users/doe/.dirac/playground'
Compiling playground project...
Starting playground HTTP server on port 9112
Booting Dirac Agent...
Starting nREPL server v0.7.0 on port 36180
Dirac Agent v1.6.0
Connected to nREPL server at .
Agent is accepting connections at .
Launching Chromium [with --user-data-dir='/Users/doe/.dirac/chromium/profiles/default'] ...
[52115:775:0806/215217.364371:ERROR:(208)] [21:52:17.344] FIDO:  Touch ID authenticator unavailable because keychain-access-group entitlement is missing or incorrect

reefersleep19:08:45

Same type of errors though, things not being defined and all that.

darwin19:08:43

so those errors are present only when you add dirac dependency to your project?

reefersleep20:08:17

Well, no - not when I run the app in regular Chrome. Only in Chromium.

reefersleep20:08:06

As started by Dirac.

reefersleep20:08:19

Maybe I should try just running Chromium without dirac and see if the app works there…

darwin20:08:20

so try it in chromium without dirac

reefersleep20:08:05

Yeah, works fine there, too.

darwin20:08:43

there are two things, 1) chromium with dirac breaks things 2) dirac runtime in your app break things

darwin20:08:10

if you test your app compiled with dirac runtime in normal chrome/chromium, does it work?

reefersleep20:08:46

Yes, that’s what I’m doing now.

darwin20:08:52

I guess 2 is the case, because it dirac runtime brings some deps which might clash with your existing deps

reefersleep20:08:52

No errors of any kind.

reefersleep20:08:38

It seems to be 1).

reefersleep20:08:33

But you are right; when I used dirac as a :dev profile dependency, there were clashes. Perhaps now that I’m using it as a part of the normal :dependencies vector, there are clashes that I don’t see.

reefersleep20:08:51

For whatever reason.

reefersleep20:08:41

Yeah, lots of suggested :exlusions from lein deps :tree…

reefersleep20:08:56

Perhaps I should try those before I do anything else 🙂

reefersleep20:08:16

Gotta try that tomorrow.

reefersleep20:08:38

Thank you for your time! Getting late here, heading to bed now 🙂

3
Shako Farhad09:08:00

Is there a nice way of logging stacktraces that make sense with advanced compilation turned on? :s

Mikko Harju14:08:01

Is there a trick to get the contents of a var at compile time in macros? ....no?

dnolen14:08:36

cljs.analyzer.api/ns-resolve

Mikko Harju14:08:39

It seems to return the vars analysis map? Can I use it to infer the contents of the var?

Mikko Harju14:08:32

By reading the content from disk given the start and end location? 🙂

dnolen14:08:16

@mikko I misunderstood what you were asking

dnolen14:08:26

by "content" of var I thought you were talking about metadata

dnolen14:08:02

there's no such thing as vars in ClojureScript so what you're talking isn't possible

Mikko Harju17:08:01

Yes, that's what I figured. I have to come up with something else then, giving more responsibility to the runtime. Thanks anyway!

lread18:08:49

Hiya! I see the https://clojurescript.org/reference/compiler-options#target`:target`https://clojurescript.org/reference/compiler-options#target: > Valid options are :nodejs, :webworker and :bundle. > The default (no :target specified) implies browsers are being targeted. But I see https://github.com/Olical/cljs-test-runner/blob/4bb157623f610429b1740e366aaa4090743ba968/src/cljs_test_runner/main.clj#L137-L152`:browser`https://github.com/Olical/cljs-test-runner/blob/4bb157623f610429b1740e366aaa4090743ba968/src/cljs_test_runner/main.clj#L137-L152`:target`. Is this a thing? Or is it simply that an unrecognized :target also chooses the default?

dnolen19:08:43

@lee unrecognized I'm pretty sure

p-himik19:08:55

cljs.core/find-ns-obj throws on any target other than nodejs, webworker, or default. That is, unless *target* there is something else entirely.

lread19:08:57

Thanks for replies! I see a https://github.com/clojure/clojurescript/blob/f5f9b79f6f446cef768e190971cf67fc78bf5b93/src/main/clojure/cljs/closure.clj#L1745`cljs.closure/output-main-file`. I wonder if the cli usage help for target might mislead a bit in its wording? 

-t, --target name          The JavaScript target. Configures environment 
                              bootstrap and defaults to browser. Supported 
                              values: node or nodejs webworker, none
target defaults to browser but browser is not a supported value.

lread19:08:11

(Just thinking out loud how :browser might have been considered a valid val for target)

dpsutton20:08:57

devcards is super awesome. getting it back into our codebase and just remembering how great it is

💯 9
ejelome21:08:12

... Good eve, just a quick question: Does anyone know the reason why GraalJS was removed recently? I can't seem to find the reason behind its removal (it was removed along with Rhino and Nashorn which is understandable because they were declared obsolete and unmaintainable in OpenJDK), but for GraalJS, googling didn't help. Here's the link where I read it: https://clojurescript.org/news/2020-04-24-release

ejelome11:08:23

Hey thanks! So it's more or less a maintenance issue just like how OpenJDK decided to remove Nashorn.