membrane 2022-08-12

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

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

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

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?

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

do you need IDraw for testing?

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.

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

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.

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

👍 1

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

If that was a performance consideration

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

which is kind of orthogonal to other improvements

anyway, I'll create a github issue

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

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

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

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

is that from switching back and forth between different versions?

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

putting the error in a seperate thread

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

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

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

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

Ah good question

Doesn't help

I guess there's also the -Sforce

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

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

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

oh weird

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

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

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

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

Sorry I had to head out

👍 1

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

Yes was running from root

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

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

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