Clojurians Log v2

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") )}]

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, …}

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

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

@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

See https://github.com/borkdude/sci#stdout-and-stdin

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

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

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

I'll make an issue as a reminder

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

:thumbsup:

it's just for debugging I presume?

yeah

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

ah cool, i’ll check

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

what happens when you do that?

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

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

why did you need to re-define set!?

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

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

aha, might be worth an issue I think

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

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

I guess you are right https://github.com/borkdude/sci/blob/5d958bf28319ef34bacb533282b1fdd2fe440df3/src/sci/impl/interpreter.cljc#L467

can you make sci interpret an expression step by step?

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?

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

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.

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

So you could try adding that to your sci config

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

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.

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 :)

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