This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-14
Channels
- # announcements (4)
- # aws (7)
- # babashka (44)
- # beginners (178)
- # calva (15)
- # cider (3)
- # clj-kondo (15)
- # clojure (139)
- # clojure-dev (8)
- # clojure-europe (2)
- # clojure-italy (2)
- # clojure-losangeles (9)
- # clojure-nl (32)
- # clojure-spec (6)
- # clojure-sweden (1)
- # clojure-uk (27)
- # clojurescript (17)
- # core-typed (116)
- # cursive (26)
- # data-science (1)
- # datomic (14)
- # duct (16)
- # emacs (9)
- # events (1)
- # fulcro (47)
- # jobs (3)
- # juxt (6)
- # keechma (2)
- # malli (59)
- # mid-cities-meetup (8)
- # off-topic (32)
- # pathom (5)
- # reagent (2)
- # remote-jobs (4)
- # rewrite-clj (16)
- # shadow-cljs (14)
- # spacemacs (9)
- # sql (27)
- # tools-deps (37)
- # vscode (7)
Try (if 1)
:p
Random shower thought... Would it be a big performance hit if Sci would support I18n? E.g. meaning error messages in other languages?
Sci could make Clojure more accessible to non-programmers, what if it could make programming more accessible to non-English speakers... 😎 Just saying
I have a branch where I promote all clojure.core vars to "real" sci vars and it just copies the metadata from the clojure vars:
$ ./bb '(clojure.repl/doc inc)'
"Returns a number one greater than num. Does not auto-promote\n longs, will throw on overflow. See also: inc'"
I wonder if this will be noticeable in performance hit. Feel free to test; the branch is copy-vars
.Cool, sounds like it is an option when needed
Maybe at some point you want to have a sci-min and sci-full or something to support different use cases
the reason for this is this issue: https://github.com/borkdude/sci/issues/263
but it's also nice to have when you expect resolve
always to return a var. right now it can just return a function in sci, when there is no var in between
Yeah makes sense to have it in that use case. But let's say you want to use Sci on a website, you wouldn't want to add unnecessary data I think. Sci could have a small core and have some addons?
The binary size of bb isn't affected that much, so I guess it's ok in the regard. It does take a small perf hit for tight loops: https://github.com/borkdude/sci/issues/263#issuecomment-586166717
yeah, it's the same with excluding functions you don't want. e.g. if you don't want clojure.string, etc.
that's the hard part of an interpreter: you don't know what people are going to do with it, so you have to include everything
Yeah i understand, np. There is also always the options to let people make custom compilations (like i'm doing for my Lambda code)
That way you give a full experience and if others want to optimize to their use case they can (with a little work)
right. I guess you can also fork sci and make some tweaks, and then optimize it for your use case
although it would be nicer if sci offered that option. in the case of minified js on npm that's not doable, you have to get everything in there
for my current use case it isn't
I think it's ok until someone can convince you 🙂
yeah, maybe I shouldn't worry too much about other people's problems until they tell me 😉
One thing I don't know how to fix yet, which would be nice i think, is how I can make two sci packages work together
so if you have the normal sci package and you have another one. They cannot really work together because clojure datastructures are not minified in the same way
so sci might encode a map {:a 1}
like {g: "a", k: whatever}
and the other lib does it different like {f: "a", k: whatever}`
If we can solve that problem, you can abuse npm
for sci libraries 🙂
in this case it was my AWS library. But now i compile it together with my custom sci to make it work
That's ok, but it would be more powerful if you can have arbitrary combination of libs
I guess that's the way to go then. I don't think I can work around advanced compiled code
I think we can, but i'll leave it for later 🙂
I'm thinking if mori.js can do it, we can do it
The nice thing about reified core vars is that you can also do stuff like:
$ ./bb "(ns-name (:ns (meta #'clojure.string/join)))"
clojure.string
I think in practice reified core vars won't be noticable in performance, only in tight loops, and that kinda sucks anyway in an interpreter 😛
test:
./bb -e "
(time (require '[spartan.spec :as s]))
(time (s/explain (s/cat :i int? :s string?) [1 :foo]))
(time (s/conform (s/cat :i int? :s string?) [1 \"foo\"]))
"
bb before:
$ script/lib_tests/spartan_spec_test
"Elapsed time: 58.360306 msecs"
:foo - failed: in: [1] at: [:s]
"Elapsed time: 3.873929 msecs"
"Elapsed time: 0.783616 msecs"
{:i 1, :s "foo"}
bb with reified core vars:
$ script/lib_tests/spartan_spec_test
"Elapsed time: 60.589979 msecs"
:foo - failed: in: [1] at: [:s]
"Elapsed time: 3.936975 msecs"
"Elapsed time: 0.642132 msecs"
{:i 1, :s "foo"}
Nice 🙂
Like the binary size log, are you also keeping a performance log somewhere?
@jeroenvandijk When there are changes that are likely to make an impact on performance, I do measure it