I am having trouble with evals that involve js classes. I use sci in browser, and have this config: :classes {'js goog/global :allow :all}

I exported j/get and j/call from applied-science/js-interop and this is working: (-> (j/get js :console) (j/call :log 34)) But both of this is getting the error symbol not found: (.log js/console "hi") js/Math.PI

I also use :bindings {'js goog/global}

I think I tried every possible combination already.

It is very weird, as the unit tests in sci clearly work with classes in this way.

@hoertlehner don't use :bindings, just the :classes config should make this work. Instead use :namespaces to include js-interop

you can check #nbb which also has js-interop in its SCI config

and also the same config for :classes

So has scittle which is a SCI-packaged-for-browser

https://github.com/babashka/scittle

$ npx nbb
user=> js/Math.PI
3.141592653589793

you can also make a repro repository and I'll take a look if you don't find what you need after these hints

thanks a lot @borkdude

(scittle doesn't have js-interop but nbb has)

so if I do not export js in bindings, then the eval of js/Math.PI gets me "Could not resolve symbol: js/Math.PI"

(defn compile-code [code] (try {:result (sci/eval-string code ctx-repl)} (catch :default e ;(error "sci compile-code --]" code "[-- ex: " e) {:error {:root-ex (.-data e) :err (.-message e)}})))

could it be related to eval-string vs eval-string* ?

Did you first make a context before this?

Then you should use (`eval-string* ctx code)` , not (eval-string code opts)

opts != ctx

so eval-string* is cllled with contex

and eval-string with options.

I always had eval-string with context.

and it all worked,

except for the classes.

Thanks @borkdude I woul dnever have found out the eval-string* vs eval-string difference.

yes, that's the case. cool that it works now

Is there any development for async load-fn ?

In goldly, I have an extension system, and there are many files that only ship sci code

So currently I am pushing from clj all sci source code files,

and this way I can use load-fn synchronously.

but this approach only works while the number of files that have sci source code are small.

I was thinking that I run eval 2 times.

One time just to find out which source code files I need.

And the other time, where all source code files are loaded, I return that eval result.

So first time I have to run eval-string on a context that is forked off

@hoertlehner #nbb has an async way of loading JS files. This is implemented by manually handling all top level expressions. When the top level is ns or require it provides its own async implementation and for the rest of the expressions it just invokes SCI as usual. Eventually that may come to SCI but right now it's incubating in that project.

and the second time I use the repl context.

yeah, there are various ways to work around this

So far the nbb approach is quite nice, but it's based on promises and promises might be controversial vs callbacks for example

So it's a bit too early to decide on a good approach. Instead I might document how its done in nbb so people can just borrow that approach

But of course you can look at the code today already

thanks!

I will!

https://github.com/pink-gorilla/goldly

In goldly I have an extension system, where ui render functions can be included to the sci ui dynamically.

It works really amaingly.

https://github.com/pink-gorilla/reval/tree/master/src/goldly/devtools

The entire devtools browser ui is implemented via sci clojure.

so I have notbook viewer, repl, scratchpad, function browser,

page explorer,

all just written in sci.

I think with goldly we have emacs in the browser,

but without the text editor part.

hahhahah

This means that with sci we can run entire dynamic webistes

https://github.com/pink-gorilla/demo-goldly

this is the demo.