clojurescript

ClojureScript, a dialect of Clojure that compiles to JavaScript http://clojurescript.org | Currently at 1.10.879
Helins 2021-01-27T01:48:52.124500Z

Here is something I have been fighting for hours. A brain twister I believe. Let us suppose 2 CLJC namespaces: <http://my.app|my.app> figures in a Clojurescript project while ns.lib is a library providing a macro. This macro takes a form which needs to be evaled. In theory, it's fine: that form comes from <http://my.app|my.app> and can be consumed both from Clojure JVM and Clojurescript. Here is the catch: evaling that form in the macro fails. I guess that while <http://my.app|my.app> has been interpreted as a Clojurescript file, it has not been interpreted as a Clojure JVM one and what the macros sees (from a "Clojure JVM point of view") is an empty namespace. As such, evaling fails as soon as this form contains a defined sym or something that is required.

Helins 2021-01-27T01:51:19.126700Z

Using (require) in the macro produces weird undefined-looking behavior. I guess this is because it induces a circular dependency (`http://my.app` using a macro from ns.lib which then needs to dynamically require <http://my.app|my.app>).

Helins 2021-01-27T01:51:50.127300Z

TLDR ; How can a macro eval a form as Clojure in a Clojurescript project?

2021-01-27T09:20:51.133600Z

hmm, maybe a gist would help. macros are clojure code that return forms which are read by the clojurescript compiler. so bc they are clojure code, you can do any clojure stuff you want, including eval.

Helins 2021-01-27T10:34:13.134100Z

Yes, however. When a macro in my.lib is called from <http://my.app|my.app>, the value of *ns* is set to <http://my.app|my.app> . That's great! The problem is that <http://my.app|my.app> , being in a CLJC file, has been loaded as Clojurescript whereas in the macro we are in the Clojure JVM world. So this fails:

(ns <http://my.app|my.app>
  (:require [my.lib]))

(def foo 42)

(my.lib/some-evaling-macro (+ foo 1))
Because foo is undefined in the Clojure JVM world since <http://my.app|my.app> has never been required. If I am talking gibberish I can write a proper gist but there is not much more to it.

2021-01-27T10:49:28.134400Z

I see now, thanks. Sorry I don't know how you could get something like that to work

Helins 2021-01-27T02:03:11.127400Z

Interesting, I don't really know lit-html but after reading more about it I am wondering if CLJS could do all the preparations lit-html does in mere macros.

sova-soars-the-sora 2021-01-27T02:21:14.127800Z

There are reader conditionals

sova-soars-the-sora 2021-01-27T02:21:33.128Z

but that's .cljc

Mikko Harju 2021-01-27T08:01:44.131800Z

Hi! Trying to get re-natal/figwheel based React Native project up and running again using the newest RN + CLJS -combination. I'm basically stuck in a point where cljs_deps.js does a goog.addDependency("math/long.js", ['goog.math.Long'], ['goog.asserts', 'goog.reflect']); that is converted to a TransformedDependency. It calls out to CLOSURE_LOAD_FILE_SYNC that is supposed to load the file synchronously in order for it to get transformed. Do I really need to create a native extension function to handle synchronous loading for this or how does e.g. shadow-cljs handle the initial loading of all the files? The CLOSURE_IMPORT_SCRIPT side is working just fine since its async, but that math/long.js -transformation step fails the loading of cljs_deps (it does not continue loading the other requirements that come after that definition)

rberger 2021-01-27T08:25:35.132900Z

Does anyone know of a current Clojurescript library or wrapper for working with webrtc?

thheller 2021-01-27T09:16:20.133400Z

shadow-cljs does not use the "debug loader" mechanism of the closure library. therefore it doesn't do the goog.addDependency or any of the CLOSURE_IMPORT stuff. for react-native stuff it just emits the files that needs to be loaded into the .js file as strings and then evals them on load. it could just emit the files directly without that indirection too but I'm trying to "hide" the code from metro so it doesn't try to process it. makes things faster and more reliable overall.

✅ 1
Mikko Harju 2021-01-27T09:41:25.133900Z

Thanks for the answer! I managed to fix this for now by making a faux sync loader that returns an empty object that then makes the goog debug loader to believe it has done its job 😄 I might be transforming the project to shadow-cljs react-native toolkit, but now is not the time to do that since this is a fairly large project and fixing the requirements is not a trivial task.

takis_ 2021-01-27T18:00:59.136500Z

Hello, ide for clojurescript with javascript support also ? intellijidea community doesn't support javascript

takis_ 2021-01-27T18:01:17.136900Z

i was thinking to try atom,any suggestions ?

clyfe 2021-01-27T18:05:57.137Z

https://calva.io

takis_ 2021-01-27T18:08:09.137300Z

i have ubuntu only i think visual studio works

takis_ 2021-01-27T18:08:15.137500Z

but not sure if all ok

takis_ 2021-01-27T18:09:05.137700Z

i tried it in past i had some problems and went to intellijdea again , i think i wwill just try them all again , thank you

clyfe 2021-01-27T18:11:40.137900Z

I use vscode on ubuntu and works

takis_ 2021-01-27T18:14:35.138100Z

good thank you i installed it again now

agold 2021-01-27T19:40:28.138700Z

No problems here with vscode on Ubuntu.

joshmiller 2021-01-27T23:36:15.141900Z

I recently needed to type hint an object from a library being loaded from an external source to get advanced compilation working. I first tried hinting it in a let-block, but that didn’t work. Then I extracted it into a function and hinted the argument and that did. Is that expected cljs behavior? The Clojure guide for Java interop says let-blocks are available type hinting locations, but I don’t know if that extends to cljs or not.

thheller 2021-01-27T23:39:31.142400Z

@joshmiller it does. as in (let [^Type foo (something)] ...)

joshmiller 2021-01-27T23:40:07.143Z

Hm, ok, not sure what my issue was then. I’ll see if I can make a minimal reproduction for either a bug or to see what I did wrong.

thheller 2021-01-27T23:40:41.143500Z

if that let is in a core.async go the typehint might get lost. core.async tends to lose that info.

joshmiller 2021-01-27T23:40:51.143700Z

Ah, it was in a go block.

thheller 2021-01-27T23:40:59.143900Z

yeah thats a bug

joshmiller 2021-01-27T23:41:08.144400Z

Cool, good to know.