Fork me on GitHub
#babashka
<
2020-02-16
>
borkdude11:02:40

clojure.repl/doc merged to bb / sci master

sogaiu12:02:13

worked on linux here:

$ ./bb "(require '[clojure.repl :refer [doc]]) (doc merge)"
-------------------------
clojure.core/merge
([& maps])
  Returns a map that consists of the rest of the maps conj-ed onto
  the first.  If a key occurs in more than one map, the mapping from
  the latter (left-to-right) will be the mapping in the result.
💤 time 🙂

wilkerlucio13:02:25

@borkdude hello, I've been playing with SCI these days, great stuff! I'm exploring using SCI to do some client-side extensions (allow user to add code), currently what I noticed is that using eval-string we just do an "all in once" compile and return. Would be possible to also retain/re-use the environment from a compilation into another? some things I'm trying to do: - after reading user code, inspect what symbols were defined (also wanna read some meta-data from them, can use to extend things on my end) - re-use the user environment, to avoid having to re-read every time before running an expression is there a way to do those currently? or plans to have something like it in the future?

jeroenvandijk13:02:55

@wilkerlucio I would be interested in seeing where your exploration takes you. I am working out a crazy idea to built the next Rails (on steroids) with Sci... In case you happen to have a similar intention maybe we can collaborate

borkdude13:02:12

@wilkerlucio yes, that's possible like this:

user=> (require '[sci.core :as sci])
nil
user=> (def env (atom {}))
#'user/env
user=> (sci/eval-string "(defn foo [] :foo)" {:env env})
#'user/foo
user=> (sci/eval-string "(foo)" {:env env})
:foo

borkdude13:02:43

does that make sense?

wilkerlucio13:02:07

yes, it does, gonna play with it now, thanks! 🙂

wilkerlucio13:02:39

@borkdude I see this option is not on the eval-string docstring, if you want I can add it there, or you prefer to keep it hidden at this point?

borkdude22:02:28

I now added this to the docs / README

wilkerlucio13:02:24

awesome! 😄

borkdude13:02:20

I was in fact thinking about a different way of doing this, so maybe it's a bit too early.

borkdude13:02:00

there is a function in sci.impl.opts called init-opts, which I'm using in babashka like this:

(def sci-opts (init-opts {:namespaces .... }))
(eval-string* ... sci-opts)
(eval-string* ... sci-opts)
where eval-string* is a function that does not call init-opts again to save a bit of performance on merging maps etc

borkdude13:02:22

init-opts will create the initial atom which will then be passed to successive calls

borkdude13:02:47

maybe it's cleaner to expose this in the API in the future without exposing the atom as an implementation detail

borkdude13:02:59

^ @wilkerlucio

borkdude13:02:26

I'll post this is an issue

wilkerlucio13:02:27

gotcha, cool, but I'm not seeing how this second solution can be used to read things defined by the user (the after read on @env), is the return of eval-string* different?

borkdude13:02:09

the sci-opts is a map with an atom in it. so if you keep passing that to each eval-string* call, the atom will be updated each time

wilkerlucio13:02:20

ah, makes sense

borkdude13:02:38

but the :env trick also works, and won't likely be broken, so feel free to use that

borkdude13:02:09

Keep an eye on https://github.com/borkdude/sci/blob/master/CHANGES.md for breaking changes, just in case.

wilkerlucio13:02:56

a bit of stretch, I'm trying this:

(let [env          (atom {})
        user-library (pr-str
                       '(do
                          (ns ^:user-fns some.new-ns)

                          (defn my-custom-fn [x] (str x " augmented"))))
        user-command (pr-str '(update-block (update-in % [:block/children 0 :block/string] some.new-ns/my-custom-fn)))]
    (sci/eval-string user-library {:env env :bindings (merge standard-lib {'% {}})})
    @env
    (->> @env :namespaces keys (filter #{'some.new-ns}) first meta)

wilkerlucio13:02:09

:user-fns doesn't show up on the meta

borkdude13:02:00

yeah, maybe the ns macro in sci doesn't support metadata yet, I'd have to check

wilkerlucio13:02:18

no worries, I can go around this, just pushing to see how far it can go :)

borkdude13:02:16

feel free to post an issue about this, it isn't that hard to get in (hopefully...)

borkdude13:02:16

feel free to post an issue about this, it isn't that hard to get in (hopefully...)