Fork me on GitHub
#shadow-cljs
<
2018-03-02
>
hlolli15:03:06

takeing it 1 step further, how can I override/js-resolve the node-repl, so that "mylib" within a .jar becomes "/mylib", this is for a project that I don't plan to build, just use the node-repl for live evaluation. To be percise, this :require https://github.com/hlolli/csound-wasm/blob/master/src/csound_wasm/node.cljs#L3 I'm hopeing to stay leagal from within a .jar file (so in another project I'm requireing this project).

hlolli15:03:12

therefore in this case I'm hopeing "libcsound" resolves to "/csound_wasm/libcsound"

thheller15:03:08

is this not available from npm?

hlolli15:03:00

yes! ๐Ÿ™‚ I'm hopeing to make this a clojurescript library, node library and a standalone browser js library.

thheller15:03:05

I mean why not juset require "/csound_wasm/libcsound"?

hlolli15:03:46

it would probably work from the .jar, but within the project itself when compileing :node-library, it will complain.. I can try again

thheller15:03:47

if you package that file in a .jar it should work for any build using that jar

thheller15:03:22

it just has to be on the classpath

hlolli15:03:42

that's true, I bet it would, I'm going to see now if that will ruin the shadow-cljs release node compilation.

thheller15:03:25

no :js-options at all

thheller15:03:08

always just require "/csound_wasm/libcsound" not libcsound

hlolli15:03:52

yup that works! now confirming the .jar

hlolli15:03:21

but I do get some errors from "/csound_wasm/libcsound" that I didn't get from "libcsound" + :js-resolve. Namely

Closure compilation failed with 7 errors
--- csound_wasm/libcsound.js:81
Invalid module path "goog:shadow.js.shim.module$fs" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:82
Invalid module path "goog:shadow.js.shim.module$path" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:4253
Invalid module path "goog:shadow.js.shim.module$crypto" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:5166
Invalid module path "goog:shadow.js.shim.module$ws" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:5416
Invalid module path "goog:shadow.js.shim.module$ws" for resolution mode "BROWSER"
--- remaining errors ommitted ...

hlolli15:03:37

so ok, I guess it didn't compile then, I was running an older output

thheller16:03:28

so what is happening there is that you have conditional requires

hlolli16:03:43

this file is kinda shit, automatically generated js->c/c++ patch from emscripten compiler

thheller16:03:43

those are generally a bad idea and not supported

hlolli16:03:47

I wonder why it still differs, the :js-resolve and classpath require. The setup with :js-resolve, minified it all and didn't throw errors.

thheller16:03:10

it is treated differently

thheller16:03:07

hang on I'll check something

thheller16:03:20

make: Entering directory '/mnt/c/Users/thheller/code/shadow-cljs/tmp/csound-wasm/node_modules/speaker/build'
  CC(target) Release/obj.target/output/deps/mpg123/src/output/alsa.o
../deps/mpg123/src/output/alsa.c:19:28: fatal error: alsa/asoundlib.h: No such file or directory
 #include <alsa/asoundlib.h>

thheller16:03:28

guess its not available on windows

hlolli16:03:50

ahh, f** "speaker"

thheller16:03:11

does osx work?

hlolli16:03:47

yes it should

hlolli16:03:52

I can test 1 sec...

hlolli16:03:28

they say for windows Windows: win32 Audio output for Windows (winmm). whatever winmm is, need to look into that. Webaudio in node.js is a strange world.

thheller16:03:56

it might be because of WSL

thheller16:03:03

where does the libcsound.js come from?

hlolli16:03:53

but I added this module.exports = Module at the end of the file. the minifier would otherwise not find the object.

thheller16:03:53

ok so the compromise I made

thheller16:03:07

was that the classpath should only contain ES6

thheller16:03:24

but yours is commonjs with dynamic requires

thheller16:03:47

so it should be treated like node_modules sources but isn't at the moment

thheller16:03:28

let me see if I can reasonably change the behaviour

hlolli16:03:37

ok, otherwise I could see if it's reasonable to patch this file to become ES6 compatable, but that sounds daunting

thheller16:03:04

ideally it wouldn't include the loading code at all

thheller16:03:13

and would you just let pass in the wasm code

thheller16:03:34

would be good if there was a way to generate libcsound_browser.js libcsound_node.js

thheller16:03:44

so the file itself doesn't include any conditional loading code

hlolli16:03:22

hmm, then there's the rust to wasm compiler, seperate of emscripten one, looking at wasm discussion in the wild, seems to be an overtake from the rust community.

hlolli16:03:08

yup aggree, I bet this will be improved soon

hlolli16:03:07

no they use emscripten seemingly... nvm...

thheller16:03:01

meh this commonjs handling code of the closure compiler hurts my head

thheller16:03:39

I'll probably add a new source type that isn't processed by closure at all

thheller16:03:53

and just copied as is to the output dir

thheller16:03:07

that should resolve the problem for node

hlolli16:03:46

I would still be tempted to compile it with js-resolve and change the require form and then bundle the jar. But the feature of ignoring certain js deps to be processed by closure is going to save headaches.

hlolli16:03:27

No quatsch, wont work :)

hlolli16:03:55

Yes I really need to ignore option for the jar.

thheller16:03:18

how come you don't just publish libcsound.js to npm independently?

hlolli16:03:10

That was my initial plan. Was curious of the new features in shadow-cljs. But from this position, sounds way easier

thheller16:03:45

well closure is getting in the way here

thheller16:03:26

Invalid module path "goog:shadow.js.shim.module$fs" for resolution mode "BROWSER" this I can fix easily

hlolli16:03:41

Or the third option, i dont make a jar at all and require the npm

thheller16:03:46

jar for cljs is fine. jar for es6 is experimental but should be fine. jar for commonjs is broken.

hlolli17:03:33

Yes, then I dont stress about this, bundle the libcsound when/if emscripten compile better js binding files

thheller17:03:37

the problem is that I can't stop closure from rewriting require

thheller17:03:14

but it shouldn rewrite require("fs")

hlolli17:03:10

Well, deep in this emscripten js jungle is their own FS bindings. So I could see why this confuses the compiler

hlolli17:03:26

Node 4.x filesystem bindings

thheller17:03:53

nono the problem is that closure rewrites require calls

thheller17:03:03

and replaces them with direct variable references

thheller17:03:15

but it shouldn't rewrite those requires

lilactown18:03:05

it feels like integrating so heavily with google closure was not a good move for CLJS ๐Ÿ˜ž a lot of problems with CLJS today are caused by itโ€™s dependence on it

thheller19:03:18

@lilactown CLJS does not depend on it at all. I could do everything without the CLJS compiler. Closure is just far beyond every other JS tool out there when it comes to optimizing JS and I personally don't want to give that up.

thheller19:03:34

we are just using the closure compiler for things its not yet super optimized to do

thheller19:03:06

so technically CLJS doesn't have any issues with closure. non-closure-js has.

thheller19:03:22

could be using babel for that part but I wanted to enable DCE for .js on the classpath

thheller19:03:35

that might be a dead-end so I should probably opt out of that for now

thheller19:03:08

already opted out for node_modules