Fork me on GitHub
#sci
<
2021-11-08
>
awb9913:11:46

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}

awb9913:11:20

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

awb9913:11:12

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

awb9913:11:28

I think I tried every possible combination already.

awb9913:11:24

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

borkdude13:11:07

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

borkdude13:11:23

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

borkdude13:11:01

and also the same config for :classes

borkdude13:11:16

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

borkdude13:11:37

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

borkdude13:11:15

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

borkdude13:11:31

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

awb9914:11:50

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"

awb9914:11:11

(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)}})))

awb9914:11:27

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

borkdude14:11:41

Did you first make a context before this?

borkdude14:11:16

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

borkdude14:11:27

opts != ctx

awb9914:11:24

so eval-string* is cllled with contex

awb9914:11:29

and eval-string with options.

awb9914:11:38

I always had eval-string with context.

awb9914:11:40

and it all worked,

awb9914:11:46

except for the classes.

awb9914:11:25

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

borkdude14:11:08

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

awb9915:11:48

Is there any development for async load-fn ?

awb9915:11:43

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

awb9915:11:00

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

awb9915:11:11

and this way I can use load-fn synchronously.

awb9915:11:37

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

awb9915:11:43

I was thinking that I run eval 2 times.

awb9915:11:54

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

awb9915:11:15

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

awb9915:11:42

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

borkdude15:11:48

@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.

awb9915:11:48

and the second time I use the repl context.

borkdude15:11:15

yeah, there are various ways to work around this

borkdude15:11:00

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

borkdude15:11:37

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

borkdude15:11:45

But of course you can look at the code today already

awb9915:11:24

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

awb9915:11:30

It works really amaingly.

awb9915:11:03

The entire devtools browser ui is implemented via sci clojure.

awb9915:11:29

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

awb9915:11:32

page explorer,

awb9915:11:39

all just written in sci.

awb9915:11:50

I think with goldly we have emacs in the browser,

awb9915:11:55

but without the text editor part.

awb9915:11:13

This means that with sci we can run entire dynamic webistes

awb9915:11:43

this is the demo.

borkdude15:11:19

It would be nice to try this demo out somewhere online :)

awb9915:11:14

I will put on a online demo soon.

awb9915:11:26

I only have two areas of problems:

awb9915:11:38

1. the async load-fn

awb9915:11:46

2. layz loading of functions

awb9915:11:00

I am using shadow-cjs lazy loader

awb9915:11:08

so that ui renderers are loaded lazyly

awb9915:11:13

This is ok for funcitons that render ui

awb9915:11:23

As while they are loading, they render just [:p "loading"]

awb9915:11:36

Now I want to include many libraries like tick.core

awb9915:11:54

And when using this libraries, I do not want to return first a value that says loading.

awb9915:11:18

But perhaps this is the same problem really.

borkdude15:11:09

Yes, I think you can do all of this using the top level expression approach I took in nbb

borkdude15:11:26

This requires you to make a sci/reader and use sci/parse-next

borkdude15:11:39

and then inspect the form for something special, then do something special async

borkdude15:11:49

or else wrap the normal evaluation in a promise or so

borkdude15:11:56

and then just use promises all the way

awb9916:11:08

I will go this way some day

awb9916:11:11

Thanks a lot!

awb9916:11:17

What I also want to do, is essentially use sci clojure to design the web app

awb9916:11:22

And then, when everything is done,

awb9916:11:30

and in case sci is not neeeded for a production app

awb9916:11:41

then regenerate all source code files that use sci clojrue,

awb9916:11:57

so that they can be compiled by shadow cljs to the most compressed bundle possible.

borkdude16:11:36

yeah, that's great