Fork me on GitHub
#shadow-cljs
<
2018-05-01
>
mjmeintjes03:05:02

Is it possible to use Conditional Reading for web-worker contexts? For example, I'm using prosemirror in one of my files. Unfortunately, prosemirror expects a global document variable, which is not available in web worker context. This makes it impossible to require the prosemirror namespace, because it throws an exception inside the webworker. I can definitely restructure the app into separate modules, but before doing that I just wanted to check because the Conditional Reading option would be much easier.

mjmeintjes06:05:21

No worries, just solved it by patching the underlying prosemirror library.

thheller08:05:25

@mjmeintjes no it only works per build. restructuring the modules is the way to go I think

pez09:05:45

I am trying to see if we can port Calva to Clojurescript one file at a time. But I’m having troubles getting the require to work for requiring JS files. I have structured the src directory the same way as under *Requiring JS* in the User Guide: https://shadow-cljs.github.io/docs/UsersGuide.html#_requiring_js

thheller09:05:32

require is very problematic. ES6 works much better if you can use that instead

pez09:05:33

Not sure I follow. It is (:require []) I don’t get to work.

thheller09:05:12

oh. how so?

pez09:05:09

Trying to require a file utilities.js at the root of the src/js directory from a cljs file in a subdirectory to src/main. But whatever I type except for "utilities" fails, Shadow says no:

The required JS dependency “../utilities” is not available, it was required by “repl/message.cljs”.

thheller09:05:55

hmm might be a bug in the resolver code

thheller09:05:02

try ./../utilities?

pez09:05:33

Tried it, didn’t work. Even tried /../utilities 😃

thheller09:05:07

ah hang on. the JS handling currently hides JS errors pretty badly

pez10:05:26

I asked shadow-cljs to be verbose, but it doesn’t give any more clues to this particular issue.

thheller10:05:38

yeah hang on. looking into it

pez10:05:50

Hanging on. Many thanks!

thheller10:05:12

which config are you using?

pez10:05:45

{:source-paths
 ["src/main"]

 :dependencies
 [[org.clojure/core.async  "0.4.474"]
  [cider/cider-nrepl "0.16.0"]
  [org.clojure/tools.nrepl "0.2.12"]]

 :builds
 {:calva
  {:target :node-library
   :output-dir "out-cljs"
   :output-to "src/js/main.js"
   :exports {:message repl.message/message}
   :modules {:main {:entries [repl.message]}}
   :devtools {}}}}

pez10:05:10

repl.message/message is a map with symbols from the module. I am hoping I can access that map from js code.

thheller10:05:17

uhm did you reorganize your files?

thheller10:05:10

are the JS files still in src but you added a src/main?

thheller10:05:10

src/js must also be in :source-paths

thheller10:05:40

but don't do :output-to "src/js/calva/main.js"

thheller10:05:54

:output-to "dist/calva.js" or so and then use that as the main in package.json

pez10:05:54

Thanks. The problem with where to output-to is that main in package.json must remain ./src/js/extension for now.

thheller10:05:21

that won't work though

pez10:05:11

So I must start with converting extension.js then maybe…

pez10:05:22

Now I get this:

[:calva] Build failure:
NullPointerException:
	shadow.build.classpath/find-js-resource (classpath.clj:1017)
	shadow.build.classpath/find-js-resource (classpath.clj:998)
	shadow.build.resolve/eval14123/fn--14126 (resolve.clj:192)
	clojure.lang.MultiFn.invoke (MultiFn.java:243)
	shadow.build.resolve/resolve-string-require (resolve.clj:227)
	shadow.build.resolve/resolve-string-require (resolve.clj:210)
	shadow.build.resolve/resolve-require (resolve.clj:393)
	shadow.build.resolve/resolve-require (resolve.clj:386)

thheller10:05:04

I just got it to compile fine with

{:source-paths
 ["src/cljs"
  "src/js"]

 :dependencies
 [[org.clojure/core.async  "0.4.474"]
  [cider/cider-nrepl "0.16.0"]
  [org.clojure/tools.nrepl "0.2.12"]]

 :builds
 {:calva
  {:target :node-library
   :output-to "dist/calva.js"
   :exports {:message repl.message/message}
   :modules {:main {:entries [repl.message]}}
   :devtools {}}}}

thheller10:05:14

how do I run this though?

pez10:05:44

Open the project in Code and hit F5.

pez10:05:48

That’s what I have too, except that I removed the :modules map. Will try with putting it back.

thheller10:05:15

no don't it isn't used

thheller10:05:22

only :exports is relevant

thheller10:05:54

ok I got the NPE. tring to figure out what that is all about

thheller10:05:57

do you really want separate classpaths?

thheller10:05:18

You could just use src/main or something and put everything in there

pez10:05:20

Probably not.

thheller10:05:59

the problem is that the files are at the top-level

thheller10:05:16

I would suggest making a src/main/calva folder and putting all the files in there

thheller10:05:26

src/main/calva/utilities.js and so on

pez10:05:00

Trying it.

pez10:05:58

Do I need the main?

thheller10:05:22

no but it is generally considered best practice in the JVM world

thheller10:05:30

so you can add src/test src/dev and so on later

pez10:05:45

Makes sense

thheller10:05:24

fixing the NPE now

thheller10:05:10

yeah so the main problem you are going to run into the the use of require and module.exports

pez10:05:45

What should I use instead?

thheller10:05:53

ES6 import/export

pez10:05:31

Thanks. Is this what is causing the NPE?

thheller10:05:46

no the NPE is caused by the top-level file

thheller10:05:12

so it is in /utilities and then tries to resolve ./state

thheller10:05:28

it first tries to get the parent of /utilities which is nil

thheller10:05:36

it expects there to be a folder 😛

pez10:05:18

So if I use source path src/main and the namespace calva.repl.message it might work?

pez10:05:50

That’s a nicer namespace anyway. 😃

thheller10:05:04

so there are two parts to this problem

thheller10:05:38

who is in charge of the build and who is in charge of loading the code?

thheller10:05:48

it works best if shadow-cljs has control over both equally

thheller10:05:56

the problem with your current approach is that shadow-cljs is building it but vscode is loading it differently

thheller10:05:40

const { message } = require('../../calva/main');

thheller10:05:42

this breaks

thheller10:05:56

because the compile file is a completely separate universe basically

thheller10:05:26

with ES6 you can do import X from "goog:calva.repl.message";

thheller10:05:42

basically directly refer to a CLJS namespace

thheller10:05:31

hmm don't know how to explain this in a simple example

pez10:05:35

That is what I wanted to do to begin with.

thheller10:05:08

the goog: prefix is a special syntax from the closure compiler to access namespaces

pez10:05:31

I will look ES6 some more.

thheller10:05:35

so I imagine you want to rewrite this one file at a time

pez10:05:50

Yes, that is the “plan”.

thheller10:05:07

and JS + CLJS talking to each other

thheller10:05:20

so the CLJS can import the JS and JS can use the CLJS

thheller10:05:36

for this to work properly you need ES6 import/export

thheller10:05:41

which should be a simple translation

pez11:05:40

Yeah, I should have been starting that translation long ago.

pez11:05:17

A minimal cljs main entry point which just uses the current extension.js should maybe solve the problem with where to output-to.

pez11:05:50

Anyway, if manualy I move the js file created by shadow to the root of where everything else lies (and use the main namespace calva to avoid the NPE) then I get things to compile and the extension to load. But I access the exported map incorrectly atm.

pez11:05:57

I now pushed an update to the wip-cljs-toolchain branch with these changes. If you want to try it, just move the generated dist/calva.js to src/main/calva before reloading the extension host.

thheller11:05:20

@pez hang on I got it working. just running into a few bugs

pez11:05:44

It is fun seeing Calva activate in the project where it is being developed. =)

pez11:05:24

I’ll be away from the computer for some hours now. Hoping I’ll be home in time so I can continue this tonight.

pedrorgirardi11:05:35

@pez, @thheller did this https://github.com/thheller/clojure4vscode/tree/migrate-to-es6/src/main/calva It’s a little bit late here so once you get back I will be away

javi13:05:48

when initing a bootstrapped compiler env with (boot/init state {.... is it posible to pass options like in a regular build def

...
:my-build {...
:compiler-options {:my-flag true}
} ....
} 
that will show in (get-in @cljs.env/*compiler* [:options]) ? looking at the source at shadow.cljs.bootstrap.browser , but first time digging under the hood... 🙂 use case is : expanding / implementing something like https://github.com/bhauman/devcards/blob/ae6d1a459b91cfbccb4594c0e6970b2de289a4b3/src/devcards/core.clj#L133 deftest macro that works across cljs/browser.

thheller13:05:24

@fj.abanses you are passing the state to init

thheller13:05:29

just set in it state?

javi13:05:33

(defonce c-state (cljs/empty-state))
(swap! c-state assoc-in [:options :my-option ] false)

(defonce _ (boot/init c-state
                    {:path         "/js/bootstrap"
                     :load-on-init '#{b2repl.user}}
                    (fn []))
I did, it works. I wasnt sure it was the right way. Thanks

thheller13:05:11

it is. boot/init is just about loading pre-compiled code. does nothing beyond that

gnl13:05:18

Getting this with shadow-cljs check:

Failed reading cache for scratchpad.core: com.fasterxml.jackson.core.io.JsonEOFException: Unexpected end-of-input: expected close marker for Array (start marker at [Source: [email protected]; line: 1, column: 1028532])
 at [Source: [email protected]; line: 1, column: 1033075]
Failed writing cache for scratchpad.core: java.lang.Exception: Not supported: class java.util.regex.Pattern

gnl13:05:02

And shadow-cljs check takes quite a while to finish, which may as well just be the Closure compiler, but if it's slow due to the cache failing for some reason, it'd be great if it could be sped up.

thheller13:05:21

compile doesn't complain about cache?

thheller13:05:36

or release? or watch?

gnl13:05:02

watch doesn't, release dunno, checking now with newest version

thheller13:05:23

is this open source code? wonder where the pattern is coming from? probably somewhere in meta?

thheller13:05:24

easy to fix. just wondering why it only occurs in check

gnl13:05:34

okay, watch isn't complaining, release is:

Failed writing cache for scratchpad.core: java.lang.Exception: Not supported: class java.util.regex.Pattern

gnl13:05:39

It's not open source yet, will be soon

thheller13:05:59

stop the watch and do a single compile please

thheller14:05:24

just want to confirm that all phases complain. doesn't make sense for watch not to complain

gnl14:05:25

I tested release first, before starting the watch, will do again, hang on...

thheller14:05:45

watch just uses the cache once otherwise it'll be in memory already

thheller14:05:55

so it won't complain about cache failing

gnl14:05:01

Failed writing cache for scratchpad.core: java.lang.Exception: Not supported: class java.util.regex.Pattern

gnl14:05:13

On shadow-cljs compile

gnl14:05:19

Could it be relevant that 1. this a .cljc file with macros and reader conditionals and 2. I'm using the lein integration with shadow?

gnl14:05:01

I'm also getting these:

WARNING: failed to inspect resource "jar:file:/[....]/scratchpad/core.cljc", it will not be available.

gnl14:05:48

No idea if it's related in any way, but it's the same file.

thheller14:05:51

maybe a bad ns form?

thheller14:05:56

check the logs

thheller14:05:38

if it doesn't contain any CLJS code just make it a .clj file

thheller14:05:14

it fails compilation despite being not available?

thheller14:05:22

that doesn't make sense

gnl14:05:24

Compilation succeeds actually

thheller14:05:02

so you didn't get the inspect resource error?

thheller14:05:11

I'm confused

gnl14:05:25

It's just a WARNING, the inspect resource thing

gnl14:05:39

It then goes on to display a build completed message

thheller14:05:01

hold on for a second

thheller14:05:31

IF! you get WARNING: failed to inspect resource "jar:file:/[....]/scratchpad/core.cljc", it will not be available. the file will not be available

thheller14:05:43

and thus NEVER can be compiled successfully

thheller14:05:54

so you either got that error some time ago and fixed it in the meantime

thheller14:05:58

or something else is going on

gnl14:05:07

❯ shadow-cljs compile scratchpad                                                                                                                      1s 862ms
shadow-cljs - config: /Users/gnl/Code/re-frame-playground/shadow-cljs.edn version: 2.3.14
shadow-cljs - running: lein with-profile +shadow run -m shadow.cljs.devtools.cli --npm compile scratchpad
May 01, 2018 5:00:53 PM clojure.tools.logging$eval870$fn__874 invoke
WARNING: failed to inspect resource "jar:file:/Users/gnl/.m2/repository/gnl/scratchpad/0.1.0-SNAPSHOT/scratchpad.1.0-SNAPSHOT.jar!/scratchpad/core.cljc", it will not be available.
May 01, 2018 5:00:53 PM clojure.tools.logging$eval870$fn__874 invoke
WARNING: failed to inspect resource "jar:file:/Users/gnl/.m2/repository/zprint/zprint/0.4.7/zprint-0.4.7.jar!/zprint/main.cljc", it will not be available.
[:scratchpad] Compiling ...
May 01, 2018 5:01:00 PM com.google.javascript.jscomp.LoggerErrorManager println
WARNING: node_modules/highlight.js/lib/languages/tp.js:14: WARNING - String continuations are not recommended. See 
    begin: '(AR|P|PAYLOAD|PR|R|SR|RSR|LBL|VR|UALM|MESSAGE|UTOOL|UFRAME|TIMER|\
           ^

May 01, 2018 5:01:00 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 0 error(s), 1 warning(s)
------ WARNING #1 --------------------------------------------------------------
 File: node_modules/highlight.js/lib/languages/tp.js:14:11

 String continuations are not recommended. See 
--------------------------------------------------------------------------------

nil
Failed writing cache for scratchpad.core: java.lang.Exception: Not supported: class java.util.regex.Pattern
[:scratchpad] Build completed. (602 files, 483 compiled, 0 warnings, 49.68s)

thheller14:05:49

I assume you are working on scratchpad so why is scratchpad.1.0-SNAPSHOT.jar on the classpath?

thheller14:05:03

the SNAPSHOT jar probably contains an older version which is then overwritten by your source files

thheller14:05:07

so everything is fine

thheller14:05:12

still confusing but fine

gnl14:05:40

I had the jar installed with lein install because I was messing around with lein checkouts before shadow-cljs and now I'm directly referring the source-path of the current version

thheller14:05:55

but why is it on the classpath?

thheller14:05:14

ah ok you have it in your deps?

thheller14:05:37

ah nvm I get it now 😛

gnl14:05:40

Yes, lein checkouts supposedly needs that

gnl14:05:47

I'm not using nvm. 🙂

thheller14:05:55

nevermind 😉

gnl14:05:00

What a mess. 🙂

thheller14:05:19

ok the jar is just outdated but not a problem since you have the sources directly available

thheller14:05:20

that is fine

gnl14:05:21

Okay, so the .jar is irrelevant in this case and I can safely ignore the message?

thheller14:05:24

just ignore the warning then

thheller14:05:42

confusing as hell if you delete a file but still leave it in the jar

gnl14:05:53

I'll remove the .jar

gnl14:05:04

No need for lein checkouts anymore

thheller14:05:09

spent an hour or so once debugging this. couldn't figure out how it could still load a file that I just deleted 😛

thheller14:05:40

anyways ... the cache issue

gnl14:05:45

Those are the best issues, when you start questioning the very fabric of reality. 🙂

gnl14:05:54

Probably best to open an issue when the source is online

gnl14:05:05

Before we waste time guessing what might be going on

thheller14:05:15

just grep the source for #" please

thheller14:05:32

is it used in any metadata or so?

thheller14:05:46

just need to find out where the regex is coming from

thheller14:05:11

seems weird that it would leak into the compiler data but could be totally fine

gnl14:05:15

It's used in a spec

gnl14:05:21

and in a (comment) block

gnl14:05:34

I can try removing the (comment) block

thheller14:05:21

that shouldn't do anything

thheller14:05:34

it is never compiled

thheller14:05:10

I know how to fix it but I want to find out WHY it happens first

gnl14:05:16

I'll remove it from the spec too, hang on

thheller14:05:33

if must be a regex in that file so it can't be in too many places

gnl14:05:00

It's just those two, comment and spec

thheller14:05:00

(s/def ::foo #"hello world") this is fine so thats not it

gnl14:05:03

checking...

gnl14:05:25

Hah! Got it:

(s/def ::color (s/or :keyword keyword?
                     :literal (s/and string?
                                     #(re-matches #"#[a-fA-F0-9]+" %)
                                     #(or (= (count %) 7) (= (count %) 4)))))

thheller14:05:59

indeed! thx

thheller14:05:10

wonder why that ends up in the analyzer data

gnl14:05:13

That keyword ends up in some metadata and you mentioned something about metadata before, is that a good direction?

thheller14:05:54

ah right. its the specs getting serialized. forgot about that.

gnl14:05:57

The caching working doesn't make any difference to how long shadow-cljs check takes though, so apparently that's just the Closure compiler needing a while. Is there any way to speed this up, do you think? Somehow just recheck changed files or something or does it need to go over the whole project every time?

thheller14:05:13

define long?

thheller14:05:31

wow hmm shouldn't take that long

thheller14:05:45

take a second or two in my code

gnl14:05:07

To describe the environment - it's a playground project with many dependencies one of which is the library that I'm currently working on.

gnl14:05:16

Based on re-frame

gnl14:05:22

and lots of the warnings are in re-frame and reagent

thheller14:05:37

[:scratchpad] Build completed. (602 files, 483 compiled, 0 warnings, 49.68s)

thheller14:05:56

is that all CLJS?

thheller14:05:01

or lots of JS deps as well?

thheller14:05:15

49sec seems really slow as well

gnl14:05:31

Just cljs

thheller14:05:38

but yes check always checks all files. can't do a partial check.

gnl14:05:40

Which makes sense in a way, but some sort of caching would be nice, I'd love to be able to do the type-checking at a similar speed as hot-reloading.

thheller14:05:21

that would take a pretty significant rewrite of the closure compiler

thheller14:05:43

its not currently set-up to do this live

thheller14:05:19

you could make an extra build

thheller14:05:25

that only includes the namespace you want to check

thheller14:05:34

so not your main entry for everything

thheller14:05:42

only a partial subset

thheller14:05:54

ie. shadow-cljs check-ns cljs.core or something like that

thheller14:05:08

not sure how useful that would be in your case

thheller14:05:52

but the way the closure compiler does this means that you must provide all the sources and dependencies

thheller14:05:08

and currently you are only allowed to run it once. second attempt will fail.

thheller14:05:19

so you must throw away the previous instance and start fresh

thheller14:05:23

ie. no cache (for GCC)

thheller14:05:38

cljs is cached regardless

thheller14:05:57

maybe they support incremental checks and I just haven't found it in the API yet

thheller14:05:21

just published [email protected]. should fix the cache issue

gnl14:05:26

Okay, this clears up a few things, thanks. I don't think a single-ns check will do the trick for my use case, but I'll let you know when I finish my thing, it'll be clearer what I have in mind and then we can brainstorm some more about how best to approach this if at all possible.

gnl14:05:44

Alright, testing...

thheller14:05:03

probably won't make GCC any faster

thheller14:05:14

how long does release take?

gnl14:05:04

50+ seconds

gnl14:05:59

Let me check again...

gnl14:05:13

Okay, so:

shadow-cljs check
[:scratchpad] Build completed. (161 files, 0 compiled, 0 warnings, 4.80s)
34s 786ms

shadow-cljs release
[:scratchpad] Build completed. (161 files, 130 compiled, 0 warnings, 41.58s)
55s 530m

gnl14:05:06

What's the discrepancy between the time reported in build completed and the actual time it took?

gnl14:05:37

I'm assuming in the case of check that's where the actual checking happens

gnl14:05:27

btw the caching issue's fixed in 2.3.15, thank you!

thheller15:05:22

try running with --verbose

thheller15:05:08

do you not have a server running?

gnl15:05:05

I do when watching, haven't really done any release builds yet and just started checking

thheller15:05:38

definitely always have a separate npx shadow-cljs server running

thheller15:05:50

makes all commands a whole lot faster since you don't have to pay for the startup each time

thheller15:05:30

probably takes 20sec to just start things and warm up before anything actually related to check happens

gnl15:05:04

Oh wow, clearly I've severly underestimated the startup time of the whole thing. (shadow/check ...) in the REPL is done in 14seconds now.

gnl15:05:16

Still not great, but way better.

thheller15:05:20

yeah startup is painfully slow

gnl15:05:25

Thank you!

thheller15:05:58

14sec is still not ideal. try (shadow/check :scratchpad {:verbose true})

thheller15:05:19

most of the time is probably spent in check itself

thheller15:05:30

probably can't make that faster

gnl15:05:58

Yup, will probably have to cut down on dependencies, but will check verbose true first

gnl15:05:16

Yeah, about 12 seconds on checking, the rest on loading stuff from the cache

thheller15:05:45

hmm yeah. dunno if there are flags in the closure compiler I'm supposed to be setting

thheller15:05:58

checksOnly supposedly turns off all the slow stuff

thheller15:05:02

but maybe not everything

thheller15:05:39

its not super reliable to begin with anyways

gnl15:05:48

Maybe :closure-warnings makes a difference in that it doesn't only control reporting but actual checking?

thheller15:05:30

in most cases it only controls whether a warning is emitted or not

thheller15:05:41

sometimes it does enable the entire check too though

thheller15:05:04

gotta go. I'll be back in a few hours.

gnl15:05:28

Cool, thank you for the help!

pez16:05:17

Thanks for the help with migrating Calva imports/exports to ES6, @thheller! I have merged it into my wip branch now and it compiles and the extension loads. I pushed my branch with the changes. The extension doesn’t quite work yet, commands die silently. I guess the message module looked resonably simple to start the porting with, but it is also very central to most everything Calva does. 😃

pez16:05:22

But I’m on it and hope to be able to merge this into master soon.

pez20:05:28

Hmm, I have made some little progress, but it seems that utilities.js is sometimes not imported correctly, I get errors saying things like module$calva$utilities.X is not a function from places like hover.js and messages.cljs. However shadow.js seems to get a correct import, because it can use utilities.js functions.

pez20:05:05

And now I am too tired to think so this will have to rest a while. 😃

thheller20:05:03

@doglooksgood sorry about that. fixed in 2.3.16

👍 4
thheller20:05:02

@pez yeah the cjs-to-es6 tool I used to migrate the exports did some weird stuff

thheller20:05:50

definitely not correct it those and just accidentally works here and there

pez21:05:26

So you think I can get it working by fixing the imports manually? They look right to me. (I don’t see any difference between the imports that works and those that don’t.)

thheller21:05:09

problem is that it used export default { some, stuff, ... }

thheller21:05:30

this works if the other file does import x from "./utilities" and then does x.some

thheller21:05:51

doesn't work if it does import { some, stuff } from "..."

thheller21:05:08

can either use export without the default and adjust the others

thheller21:05:35

to use import * as util from "./utilities" and then util.<thing>

thheller21:05:02

for some reason ES6 doesn't allow "partial" refers. either all or nothing. no idea why.

pez21:05:14

Yes, now I got some more stuff to work. Thanks for the pointers!

pez22:05:36

There. Now it seems most stuff works. Maybe all stuff. I am really too tired to figure that out right now. 😃 Anyway, pushed the changes to the wip branch for anyone who cares. Calva is on it’s way to be ported to Clojurescript, thanks to shadow-cljs!

pez22:05:44

I had to do a funny trick. The new message.cljs module of course produces proper clojure maps. But the bencoder(.js) module of course has none of that. So I made a small migrate.cljs module that converts it back to a Javascript object. I use it from client.js before giving the message to bencoder. If I can port client.js to Clojurescript I will be able to remove this migration module, I think.

richiardiandrea02:05:20

Off-topic - are you building an nRepl cljs server by any chance?

pez04:05:10

Rather an nrepl cljs client. It’s an extension to VS Code, Calva. I am now curious why you asked? :face_with_cowboy_hat:

richiardiandrea04:05:42

Because I was thinking at some point about writing a lumo nRepl-compatible server of some sort. I was actually wondering which bencode library to use on JS for instance...so I guess I will observe Calva closely 😉

pez04:05:08

That would be wonderful. Then Calva could support Lumo, I think. Is it something unRepl can be used for?

pez04:05:55

Most of the client is still in JavaScript, though. The only part I have ported is the messages maps.

mjmeintjes23:05:58

Hi. Every now and again I get the following error printed by shadow-cljs:

[2018-05-01 23:27:27 - SEVERE] Unhandled REPL handler exception processing message {:ns user, :op eval, :code (ns learning.web.web-worker.core
  (:require [learning.web.module.core :as m]
            [keechma.toolbox.pipeline.core :as pp]
            [keechma.controller :as controller]
            [learning.js-utils :as j]
            [keechma.toolbox.pipeline.controller :as pp-controller]
            [goog.object :as go]))
, :file /home/matthys/projects/personal/learning/src/learning/web/web_worker/core.cljs, :line 1, :column 1, :session 6e5b0609-56d9-4d5f-9b08-91f627139e22, :id 15}
java.lang.NoClassDefFoundError: Could not initialize class shadow.cljs.devtools.errors$user_friendly_error$fn__16179
        at shadow.cljs.devtools.errors$user_friendly_error.invokeStatic(errors.clj:290)
        at shadow.cljs.devtools.errors$user_friendly_error.invoke(errors.clj:289)
Is this something you've seen before? I can create an issue and try to figure out what's causing it, but it doesn't seem to do anything bad.

Logan Powell22:05:32

@mjmeintjes I'm also trying to get setup for keechma development with shadow-cljs. Did you ever get your setup worked out?

mjmeintjes22:05:32

Yeah, I've been using shadow-cljs and keechma for a couple of months now and it works great. Let me know if you have any questions.

Logan Powell23:05:04

do you have an example repo with the configs that you could share 🙏

Logan Powell23:05:44

also, I'm using Atom with protorepl, will that be ok?

Logan Powell23:05:55

just stalked you real quick and found this: https://github.com/mjmeintjes/shadow-cljs-keechma-node Let me know if you recommend other resources (tutorials/guides/etc.)!

mjmeintjes04:05:52

That project should show you the basics, however it is a bit more complicated than needed because it also includes server side rendering using nodejs webserver. One of my goals for this month is to get a guide out on how to get started using shadow-cljs and keechma. For now your best bet is to have a look at https://github.com/gothinkster/clojurescript-keechma-realworld-example-app and keechma docs to get started with Keechma. Shadow-cljs is pretty straightforward - I'll extract my basic setup to a starter project and let you know. One important tip - have a look at https://github.com/keechma/keechma toolbox, especially datasource loaders and pipeline controllers. I know that sounds like a lot of jargon, but have a look and let me know if you have any questions. Ypu can also ask on the keechma channel, they are really helpful.

mjmeintjes04:05:13

I haven't used Atom before, so can't help you there unfortunately.

Logan Powell10:05:27

Thank you so much @mjmeintjes ! Your help is greatly appreciated! Btw, you come highly recommended by the Keechma author himself :thumbsup: