Fork me on GitHub
Slack Archive

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

2021-09-16

Channels

#clojurescript
<
2021-09-16
>
vemv10:09:18

Bit of an odd / open-ended question, but anyone recalls if under some tooling setup (like a compiler, repl, IDE) one can get .cljs files copied around as hidden / auto-generated files in your project? i.e. maybe as some side-effect, a tool is storing .random_cache/copy/of/some/ns.cljs ?

dpsutton15:09:15

been a bit since i worked on a cljs project but i remember the compiler outputs js, js.map, and cljs files from your source files during compilation

vemv16:09:21

thanks! Yes I think I remember .cljs files being outputted from the compiler. If anyone can confirm that you'd save me half an hour of undusting stuff :)

p-himik16:09:23

FWIW it doesn't seem to be the case with shadow-cljs. But I vaguely remember seeing such files when I was using lein-cljsbuild or whatever it's called.

🙂 2
👍 2
thheller17:09:27

shadow-cljs generates a bunch of cache files in .shadow-cljs/builds but generally doesn't copy raw .cljs files

👍 2
vemv17:09:49

checked ✅ indeed it's lein-cljsbuild that can copy .cljs files around. ty all!

lilactown16:09:27

I'm writing a lot of tests lately that handle promises. one thing I'd like to know is, what's the proper way to handle errors in an async test? 

(deftest async-thing
  (async done
    (-> (do-thing-that-rejects)
        (.then #(is (= 42 %)))
        (.then done done))))
this test passes despite do-thing-that-throws rejecting. we call done in either case, but what's the appropriate way to report that the test failed due to an error?

lilactown16:09:24

atm I'm doing this: 

(.then done
          (fn [e]
            (is false (str e))
            (done)))
but that feels like a workaround

p-himik16:09:36

I'm 70% certain that the same workaround is needed when you want to make an arbitrary exception to be a test failure and not a runtime exception.

p-himik16:09:53

In my code, I use (is (nil? e) ...) - seems a bit less confusing when there's a failure.

lilactown16:09:04

I'm wondering now how cljs.test reports exceptions outside of assertions, and if I could report it the same way

lilactown16:09:12

I have a macro wrapping this in actuality so it would be easy to do something like: 

(cljs.test/report {:type :error ,,,})

p-himik16:09:14

The last time I had a quick look and couldn't fine any such thing that would be public.

lilactown16:09:30

ah ok 

(do-report
            {:type :error
             :message "Uncaught exception, not in assertion."
             :expected nil
             :actual e})

p-himik16:09:13

Not documented -> not public IMO. :) Also, you will have to add all the metadata yourself. Exactly why I decided to stick with is.

borkdude16:09:34

So, I'm using .finally to call done, also when the test failed

lilactown17:09:26

nice. i actually didn't know .finally was a part of the official spec

borkdude17:09:41

is it? I hope so?

Steve Lombardi07:09:32

Useful thread. How does everyone treat unhandled promise rejections within tests? Like exceptions? What if the rejection handlers don't attach until a later run of the event loop? Being on Node 12.x I came up with something that seems to work but I'm curious what everyone here does. Node 15.x seems to have CLI flags for just this occasion but I have not verified their behavior yet.

lilactown15:09:44

I'm basically doing the above - wrapping the promise in a .finally in the first event loop

vemv16:09:21

thanks! Yes I think I remember .cljs files being outputted from the compiler. If anyone can confirm that you'd save me half an hour of undusting stuff :)

Nikita A Dudnik17:09:52

Hey! Does anyone work with Web Audio API in ClojureScript?

p-himik18:09:59

Do you have a specific problem you're struggling with or are you just curious?

Nikita A Dudnik08:09:53

No, I’m working on a library that’ll simplify working with Web Audio tremendously. Just looking for a relevant place to share it and get some feedback.

Bobbi Towers17:09:56

I tried to but it was so awkward working with something so inherently stateful. If only someone would make a nice declarative wrapper...

Nikita A Dudnik08:09:24

You’ll be surprised 🙂

p-himik18:09:37

That would be a very leaky abstraction.

Nikita A Dudnik08:09:35

why do you think so?

p-himik09:09:38

It's been some time since the last time I delved into it, so some of what I say might be wrong. But in general, audio nodes are stateful - you can't just blindly reconcile them with whatever spec you have, you have to sync them while taking their own state into account. And the issue is that they don't allow you to query some of their state or the state of the system as a whole. Take AudioNode.connect() for example - you can't query the connections that have been made. Sure, you can store that data somewhere else if the connection was made using your library - but what if you need to use some other library to come up with the audio configuration? Or what if there's something new in the API that your library doesn't account for?

Nikita A Dudnik15:09:17

I see. I’m introducing the limitation that the connection must be made using my library. It’s ok for all of the use cases I can imagine at the moment.

👍 2
lilactown18:09:19

a "React for Audio" would be fun to think about

lilactown18:09:58

I am thinking about using React's reconciler to compose music

lilactown18:09:46

no idea how it would work or what the interface would be

Chris McCormick07:09:39

you might be interested in this little toy i made a while back https://github.com/chr15m/speccy/

Nikita A Dudnik08:09:11

That’s exactly what I’m working on 🙂

Chris McCormick09:09:50

will check this out.