sci 2022-05-10 | Slack Archive

devn02:05:08

new version of http://getclojure.org is up backed by elasticsearch. It's so cool to have SCI because many things like (defn …) were barred from running in clojail, but not so in SCI. As a result the set of expressions that run successfully tripled to around 57,000

🎉 2

devn02:05:55

for most queries the first page will bore you, and the last page for the query will be… interesting

devn02:05:55

There's some cleanup to do and ranking to do for short exprs and as you mentioned things which return fns and such, but I just cracked up when I searched for iterate. Go to the last page.

devn02:05:34

http://getclojure.org/search?q=iterate&num=14 7 down

😆 1

devn02:05:33

@borkdude I did find one thing that seems wrong: print-method can pollute everything

devn02:05:31

If someone runs some code to defmethod print-method for say string, this winds up in the subsequent results

devn02:05:56

http://getclojure.org/search?q=i%27m+a+string&num=0

devn03:05:30

(sci/eval-string "(defmethod print-method String [obj w] (.write w (str \"I'm a string: \" obj)))")

(with-open [w (new StringWriter)]
  (sci/binding [sci/out w]
    (let [res (sci/eval-string "(println \"hello\")")]
      (str w))))

devn03:05:44

=> "I'm a string: hello\n"

devn03:05:09

fwiw, this was an issue in clojail as well

borkdude03:05:41

Good catch. If that bothers you, could you make an issue?

devn03:05:57

err I should be a bit more clear: it’s not “wrong” per se, but from a “treating SCI as if it’s a sandbox” standpoint, it feels like there is an assumption of a clean context on subsequent runs that doesn’t hold here

devn03:05:02

and yes, of course!

devn03:05:05

i know SCI doesn’t necessarily claim to be a sandbox, but for instance

(sci/eval-string "(defn foo [x] (inc x))")
(sci/eval-string "(foo 1)")

rightly fails to resolve symbol foo

borkdude03:05:43

Yeah, you could either remove print-method or SCI could fix it. The first time I hear this issue. Sandbox is a feature of SCI

devn03:05:18

it’s a pretty weird one, and i blame chouser for writing this in clojure IRC in like 2011 😄

devn03:05:37

the defmethod that is

devn03:05:06

i think im inclined to dig into what it would take to fix it, but of course disallowing it is an option

devn03:05:59

it feels like an oddity in that it survives separate envs and someone could register print-method and muck up future evaluation

devn03:05:05

anyway, issue incoming

devn03:05:19

https://github.com/babashka/sci/issues/726

devn03:05:15

lmk if there’s anything I can add for context. I’m also happy to take a whack at it. I’m very interested in the “why” of the issue.

borkdude04:05:08

The why of the issue is that print-method in SCI directly uses the Clojure one and that one uses a global hierarchy

👍 1

devn04:05:08

i wonder if it’s too involved/causes issues to somehow cleanse the global hierarchy across evaluations

borkdude07:05:20

That's one of the solutions I was thinking of. Another solution would be to use the hierarchy in the context and make a custom print method

didibus07:05:25

If you're concerned about security, there's still probably some functions or vars that should be off-limit no? print-method might be one of them

borkdude07:05:29

@didibus most of those things are already not included by default, but print-method slipped through :)

👍 1

borkdude08:05:51

We already have a custom print-method in SCI: https://github.com/babashka/sci/blob/afc1c010a71a0640a3c4466b7b3a1cce0ad88eee/src/sci/impl/io.cljc#L14 So if we could get access to the ctx + the ctx hierarchy there, we could solve it properly

2022-05-10

Channels