Fork me on GitHub
#sci
<
2020-07-16
>
jeroenvandijk13:07:28

I’m using to using Sci to render some html via re-agent in clojurescript. Most of the things work fine. One of the things that don’t work is using println in a callback:

[:a {:href "#" :on-click (fn [] (println "hello") )}]
In the browser console I can see:
react-dom.inc.js:481 Uncaught cljs$core$ExceptionInfo {message: "cljs.core.deref.call(...).append is not a function [at line 12, column 19]", data: {…}, cause: TypeError: cljs.core.deref.call(...).append is not a function
    at Function.cljs$core$IFn$_invoke…, name: "Error", description: undefined, …}
I’m guessing the *out* value has not been forwarded. Any suggestion here?

jeroenvandijk14:07:44

Ok i’m getting it also in other contexts not specifically related to the click handler. I’ll do some more research

jeroenvandijk14:07:17

When I define println as a binding it works like I expected. Maybe there is a better with sci/binding

borkdude16:07:01

@jeroenvandijk println et al. work when you bind sci/out to *out*. by default it's not bound to anything as to not let users cause unwanted side effects

borkdude16:07:11

I guess the mechanics of *out* are different in CLJS, so overriding println makes sense there

jeroenvandijk17:07:15

I guess it would have to be something similar to (enable-console-print!) , but I’ll stick with overriding println for now. Thanks!

borkdude17:07:27

In CLJS *print-fn* is used for this. Maybe sci should adopt sci/*print-fn* for the CLJS api, not entirely sure about this...

borkdude17:07:08

I'll make an issue as a reminder

jeroenvandijk17:07:38

ok cool. I don’t really have an idea here. I can work with the current situation

borkdude17:07:00

it's just for debugging I presume?

borkdude17:07:44

Chlorine also uses sci to render stuff using reagent, I believe

jeroenvandijk17:07:57

ah cool, i’ll check

jeroenvandijk17:07:30

I’m pretty surprised in what Sci is able to do in combination with re-agent. only things like (set! …) seem to be out of bounds

borkdude17:07:14

what happens when you do that?

jeroenvandijk17:07:07

the first is when i define set! via a binding. The second is when i define nothing

jeroenvandijk17:07:42

a work around is using (aset (js/FileReader.) "onload" (fn [] …)) in this case

borkdude17:07:50

why did you need to re-define set!?

jeroenvandijk17:07:54

because of the second screenshot. That happens when i don’t define it

jeroenvandijk17:07:36

No protocol method IBox.getVal defined for type cljs.core/Cons: (. file-reader "-onload" nil)

borkdude17:07:58

aha, might be worth an issue I think

jeroenvandijk17:07:23

Yeah I don’t fully understand what’s happening there. I guess it’s an interop thing

borkdude17:07:59

I think set! has only been implemented to set values on dynamic vars in sci

borkdude19:07:56

@jeroenvandijk I think the recommended API for setting and getting object fields in CLJS is the goog.object namespace

borkdude19:07:19

So you could try adding that to your sci config

borkdude19:07:48

Having said that, I made an issue here: https://github.com/borkdude/sci/issues/366

jeroenvandijk19:07:58

Thanks! I think you are right. I’m porting some cljs app to something in Sci. These are examples of the things I come across. I need to pick my battles in order to make some progress. For now I chose not use the filereader part :)

nahuel18:07:24

can you make sci interpret an expression step by step?

nahuel18:07:39

I saw https://github.com/JuliaDebug/JuliaInterpreter.jl is used to develop a debugger for Julia, seems like an interesting approach. I saw an issue in sci github about limiting the execution by time, but not by number of steps (or reductions in Erlang parlance). Also, can you execute an step and then resume the execution?

borkdude18:07:07

I’m currently having an internet problem and aren’t able to do anything from a laptop.

borkdude19:07:12

Ah, it seems to work now again. The limiting of execution steps or time (both are still up for discussion) are a solution for the problem of hanging evaluations. I've never considered implementing a debugger with sci so far.

nahuel19:07:16

being capable of resuming execution after limiting by steps/time can open a nice door to implement killable actors like in erlang using sci, for some usages can be nicer than core.async. Also it will be nice to being able to yield from sci interpreted code.

💯 3
borkdude20:07:53

@nahuel that is interesting, I'll have to keep that in the back of my mind for some time