Fork me on GitHub
#membrane
<
2022-08-12
>
zimablue15:08:31

hey man, something that I did is comment out a few sections which assume the existence of a browser so that I can run parts in the backend for convenient REPLING/testing

phronmophobic16:08:26

yea, adding support for that would definitely be an interesting improvement

zimablue16:08:34

there's a few possible approaches to how one dispatches , it's harder because things are being run on library import so I'm not sure how one would use eg. a global variable, I use this for electron: (def is-main? (not= (.-type (js/require "process")) "renderer")) It might be worthwhile to eliminate the things that happen on import, then one could just call a global function to post-hoc enable/disable browser-specific features

phronmophobic16:08:43

You should be able to use the full membrane.ui and membrane.component namespaces without a backend. what namespaces do you need besides those for testing?

zimablue16:08:10

interesting, I hadn't tested namespace by namespace, I just called my UI code and checked whether it worked. atm my UI code imports WebGL in several places not just at top level, eg. to implement IDraw

phronmophobic16:08:25

do you need IDraw for testing?

zimablue16:08:38

well, I want to test component-generating pipelines that output collections of components that I've implemented IDraw on, so unless I patch each component out in the backend I do need it. One can get around anything with enough mocking and patching but to me it seems simpler for the eg. "membrane.webgl" to have defaults that if browser deps don't exist it will import without throwing, instead of user/consumers of the library having to structure their code so that every component implementing IDraw has been mocked out for the unit test.

zimablue16:08:34

just a thought, it only took me adding around 5 if blocks, basically fonts and audio from what I can see/remember

phronmophobic16:08:45

I'm not a big fan of silent failure, but adjusting membrane.webgl to load the top level forms without specific browser APIs probably makes sense. Basically, it would fail on first use rather than on load.

zimablue16:08:00

If run! Exploded then I think the tests would all work fine

👍 1
zimablue16:08:29

The stuff which it's useful to run asynchronously could have errors sitting in channels/promises that will only be exposed on take! Also

zimablue16:08:41

If that was a performance consideration

phronmophobic16:08:10

another option is to write all the membrane.webgl stuff against protocols so you could mock it.

phronmophobic16:08:16

which is kind of orthogonal to other improvements

phronmophobic16:08:28

anyway, I'll create a github issue

zimablue16:08:54

thanks, I wasn't meaning to criticize just describing a usecase/workaround I'd had

zimablue16:08:08

how do I fix this "membrane needs prep" error with the latest version?

phronmophobic16:08:44

no offense taken! it's all helpful feedback! there's always room for improvement

phronmophobic16:08:53

I'm not sure how to fix the "membrane needs prep" error. how does that occur?

phronmophobic17:08:02

is that from switching back and forth between different versions?

phronmophobic17:08:48

if you're just using the cljs version, I think the prep step is completely superfluous, but I'm not sure how to appease the clojure cli

zimablue17:08:48

putting the error in a seperate thread

zimablue17:08:39

the erorr is: Error building classpath. The following libs must be prepared before use: [com.phronemophobic/membrane], the solution in clojure docs: clj -X:deps prep doesn't work, the command I'm using in general is shadow-cljs compile <my-app> or shadow-cljs watch <my-app>, nuking .shadow-cljs didn't help

phronmophobic17:08:38

what happens when you run clj -X:deps prep?

zimablue17:08:13

It doesn't fail but doesn't say that it's doing anything with membrane

phronmophobic17:08:13

does clearing the <project dir>/.cpcache directory help?

zimablue17:08:34

Ah good question

zimablue17:08:01

Doesn't help

phronmophobic17:08:27

I guess there's also the -Sforce

phronmophobic17:08:23

Do you know when the error started appearing? Did switch between different branches? Merge branches? Change dependencies?

phronmophobic17:08:24

The only other thing I can think of is to cherry-pick the following commits from the main branch: 82677ab6e492b2c8cd4871dceb540a7d890fee45 75d38cca6973a4cdd073d3c0a41cb7fb3f48ad77

zimablue17:08:44

It's when I rebased onto main from an older version, I think the deps.edn has changed to include this prep key

phronmophobic17:08:23

ok, I wonder if that means the prep step is silently failing?

phronmophobic17:08:04

what happens when you run clojure -T:build compile ?

phronmophobic17:08:45

does the directory <project dir>/target/classes exist?

phronmophobic17:08:56

are you running the prep step from the root of your project?

zimablue18:08:01

Sorry I had to head out

👍 1
zimablue18:08:24

I will check later tonight, thanks a lot for your help

zimablue18:08:34

Yes was running from root

zimablue17:08:33

clojure -T:build compile (in my project root) first errored because I didnt' have the alias in my main project deps.end, when I added that option with the same map as in phronmophobic, clojure -T:build compile did work but didn't help with the original err

zimablue17:08:42

./target/classes I don't tihnk existed, I aded it but it didn't help

phronmophobic21:08:02

ok, now that the compile step works, does calling clj -X:deps prep fix it?