This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-16
Channels
- # announcements (2)
- # aws (2)
- # babashka (29)
- # beginners (69)
- # calva (6)
- # chlorine-clover (2)
- # cider (1)
- # cljs-dev (4)
- # clojure (44)
- # clojure-israel (1)
- # clojure-spec (3)
- # clojure-uk (31)
- # clojured (2)
- # clojurescript (6)
- # code-reviews (22)
- # core-typed (133)
- # cryogen (6)
- # cursive (7)
- # datomic (25)
- # emacs (19)
- # fulcro (69)
- # graalvm (1)
- # graphql (7)
- # lumo (1)
- # off-topic (92)
- # parinfer (2)
- # pedestal (6)
- # reagent (5)
- # remote-jobs (1)
- # shadow-cljs (11)
- # tools-deps (20)
- # tree-sitter (1)
- # vim (4)
- # vscode (6)
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 🙂@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?
@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
@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
yes, it does, gonna play with it now, thanks! 🙂
@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?
awesome! 😄
I was in fact thinking about a different way of doing this, so maybe it's a bit too early.
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 etcinit-opts
will create the initial atom which will then be passed to successive calls
maybe it's cleaner to expose this in the API in the future without exposing the atom
as an implementation detail
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?
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
ah, makes sense
Keep an eye on https://github.com/borkdude/sci/blob/master/CHANGES.md for breaking changes, just in case.
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)
:user-fns
doesn't show up on the meta
no worries, I can go around this, just pushing to see how far it can go :)