Clojurians Log v2

any change of getting an utility to sci (or to a new single-purpose lib) to limit how long an sci eval can take millis? related to (https://github.com/borkdude/sci/pull/349)

it’s easy to go wrong in the user space and I think people copy&paste buggy limiters into user code bases to avoid this.

like I just inlined a code snipplet to malli, and just for cljs, and without proper threading….

#?(:clj
   (defn ^:no-doc -run [^Runnable f ms]
     (let [task (FutureTask. f), t (Thread. task)]
       (try
         (.start t) (.get task ms TimeUnit/MILLISECONDS)
         (catch TimeoutException _ (.cancel task true) (.stop t) ::timeout)
         (catch Exception e (.cancel task true) (.stop t) (throw e))))))

the Issue & PR has a lot of good links. smells like a common utility lib 🙂

@borkdude Thanks for directing me here - I looked but I must have failed to include a # sign or something like that, so I didn't see it.

I'm just starting to use sci and I'm surprised that I can't eval something like: "^{:foo true}[1 2]" and see that metadata on the result returned by eval-string.

Is that expected?

What version are you using?

Version "0.2.4".

Are you using tools.deps perhaps?

or lein?

I'm using deps.edn along with the clj command line tools.

Can you try to use the newest commit from master using a git dep? I think this was already fixed.

If that works for you can I do a 0.2.5 release tomorrow

Um ok certainly. It'll probably take a few minutes, but thank you!

I've never done this git dep thingy but I'm sure it won't be too hard.

Ok, found an example ...

borkdude/sci {:git/url "<https://github.com/borkdude/sci>" :sha "a083698ffcbfd4b81b4b5aaff96cf8d0de6fc4e1"}

Yup, that matches what I just did, thank you!

Restarting now ...

It's very neat that that feature works.

Ok compiling my app and will test with sci in a moment.

Ok, I do see the metadata there.

I also simultaneously found a bug in my own code.

I'm going to revert to the release version of sci and see if it was my bug all along.

Ok, as embarrassing as it is to say, this looks like it was probably my error all along in how I was treating the value returned from sci.

I'm using shadow-cljs to build my project, and I see a couple of whiny warnings about not being able to infer target type.

Do you think that indicates a configuration problem on my end, or is this normal?

The shadow-cljs warnings should be fixed on master as well I think. Are you still using the git dep?

I'm not using the git dep anymore, but I can test with that and see if the warnings go away. One sec.

Ok, recompiling now with the git dep again.

I still see the 2 warnings even with the git dep.

------ WARNING #1 - :infer-warning ---------------------------------------------
 Resource: sci/impl/vars$macros.cljc:107:14
--------------------------------------------------------------------------------
 104 | 
 105 | (defn push-thread-bindings [bindings]
 106 |   (let [frame (get-thread-binding-frame)
 107 |         bmap (.-bindings frame)
--------------------^-----------------------------------------------------------
 Cannot infer target type in expression (. frame -bindings)
--------------------------------------------------------------------------------
 108 |         bmap (reduce (fn [acc [var* val*]]
 109 |                        (when-not (dynamic-var? var*)
 110 |                          (throw (new #?(:clj IllegalStateException
 111 |                                         :cljs js/Error)
--------------------------------------------------------------------------------

------ WARNING #2 - :infer-warning ---------------------------------------------
 Resource: sci/impl/vars$macros.cljc:131:21
--------------------------------------------------------------------------------
 128 | (defn get-thread-bindings []
 129 |   (let [f (get-thread-binding-frame)]
 130 |     (loop [ret {}
 131 |            kvs (seq (.-bindings f))]
---------------------------^----------------------------------------------------
 Cannot infer target type in expression (. f -bindings)
--------------------------------------------------------------------------------
 132 |       (if kvs
 133 |         (let [[var* ^TBox tbox] (first kvs)
 134 |               tbox-val (t/getVal tbox)]
 135 |           (recur (assoc ret var* tbox-val)
--------------------------------------------------------------------------------

However, I should say that I do have a bootstrap build going on as well.

I don't know if that could have any impact here or not.

in general shadow warnings don't really hurt but it would be nice to get rid of them. I'll take a look

Ok, thank you for your support. I appreciate it.

In sci is it possible to do things like create a new javascript date in clojurescript?

Ie, an equivalent of (js/Date.)

I can obviously create a binding which has a function which does that.

I'm just trying to understand what js interop exists, if any.

@pmooser You can. The config for this you can borrow from: https://github.com/babashka/xterm-sci which is hosted here: https://babashka.org/xterm-sci/

Welcome to xterm-sci.
user=> (js/Date.)
#inst "2021-04-27T10:00:05.412-00:00"
user=> 

Ah, great! Thank you.

Releasing 0.2.5 now

oh crap, I forgot about the shadow warnings, cancelling...

Ok, the example you gave me (xterm-sci) was just what I needed.

It still boggles my mind that we can do this stuff with cljs in the browser.

I'm not getting any replies from #shadow-cljs, I think I'll just go ahead with the release

Ok, thank you for checking.

@pmooser Can you do one more check with commit 45a3363cc0dc09f9d6e50c7ec88fe29612597c79 to see if this fixed the warning?

Yes, one moment.

mmm edamame ...

Ok - mixed result. 1 warning is gone, 1 remains.

------ WARNING #1 - :infer-warning ---------------------------------------------
 Resource: sci/impl/vars$macros.cljc:131:21
--------------------------------------------------------------------------------
 128 | (defn get-thread-bindings []
 129 |   (let [f (get-thread-binding-frame)]
 130 |     (loop [ret {}
 131 |            kvs (seq (.-bindings f))]
---------------------------^----------------------------------------------------
 Cannot infer target type in expression (. f -bindings)
--------------------------------------------------------------------------------
 132 |       (if kvs
 133 |         (let [[var* ^TBox tbox] (first kvs)
 134 |               tbox-val (t/getVal tbox)]
 135 |           (recur (assoc ret var* tbox-val)
--------------------------------------------------------------------------------

ok, it seems shadow-cljs doesn't understand return tags from get-thread-binding-frame

releasing 0.2.5 now

Thank you!

should be there now

Hmm. I don't know how to explain this, but I saw no warnings that time.

in 0.2.5 the warnings are probably gone now

Yup. That seems to be the case. Thank you.

Is it correct that in cljs right now, with sci, the story with things like println is ... we should bind them ourselves to the normal cljs println ? (or some other function that does whatever we want it to do).

By default calling println seems to result in an opaque exception, but I see an issue in github regarding cljs printing.

yeah, sci is "safe" by default and doesn't let you mutate the outside world by default.

so you have to either bind sci/out to *out* or override println with something else

just see the xterm-sci project for an example

Oh wait, does that work?

Hmm.

I tried that (binding) ... I must have done it incorrectly.

I'll look in xterm-sci.

https://github.com/babashka/xterm-sci/blob/main/src/xterm_sci/core.cljs#L19-L22

Ah yes. I just meant I hadn't had any luck binding sci/out to *out* in cljs or whatever.

What you did there definitely works.

that might be because some functions use *print-fn* rather than *out* ?

not sure

It's ok - the example from xterm-sci is really nice, including the goog string buffer which is obvious in cljs.

It's a great starting point, and when I dig into it, if I really get stuck, I'll ask you, but the working example is definitely great.

🤌

if you think anything should be improved to the docs, (e.g. js interop, link to xterm-sci, etc) please do contribute

Sure thing. One thing I was surprised by regarding the main page is that there was very little mention of errors or exceptions or how they are returned. It becomes pretty clear once you start using it, but that seemed like an omission to me.