This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-16
Channels
- # aws (17)
- # babashka (2)
- # beginners (131)
- # bristol-clojurians (1)
- # calva (16)
- # chlorine-clover (6)
- # cider (10)
- # clara (5)
- # cljsrn (82)
- # clojure (176)
- # clojure-dev (14)
- # clojure-europe (13)
- # clojure-italy (13)
- # clojure-nl (4)
- # clojure-spec (10)
- # clojure-sweden (32)
- # clojure-uk (32)
- # clojuredesign-podcast (2)
- # clojurescript (34)
- # community-development (2)
- # conjure (17)
- # cursive (4)
- # datomic (51)
- # emacs (6)
- # figwheel-main (26)
- # fulcro (16)
- # graalvm (11)
- # jobs (2)
- # jobs-discuss (30)
- # kaocha (4)
- # meander (23)
- # off-topic (34)
- # pathom (5)
- # re-frame (10)
- # reagent (3)
- # reitit (6)
- # releases (3)
- # sci (36)
- # shadow-cljs (27)
- # sql (9)
- # testing (6)
- # tools-deps (28)
- # vim (8)
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, …}
*out*
value has not been forwarded. Any suggestion here?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
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...
ok cool. I don’t really have an idea here. I can work with the current situation
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
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
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)
Yeah I don’t fully understand what’s happening there. I guess it’s an interop thing
I guess you are right https://github.com/borkdude/sci/blob/5d958bf28319ef34bacb533282b1fdd2fe440df3/src/sci/impl/interpreter.cljc#L467
@jeroenvandijk I think the recommended API for setting and getting object fields in CLJS is the goog.object
namespace
Having said that, I made an issue here: https://github.com/borkdude/sci/issues/366
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 :)
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.