Clojurians Log v2

Change to sci-nl ?

lol?

Just a joke haha

OK, tot zover kunnen we gewoon Nederlands praten, maar laten we omschakelen naar Engels als er een niet-Nederlands iemand bij komt 😄

😂

By the way, I remember reading something in the Malli channel about trimming the sci build size for CLJS?

I don't think it's in the chat anymore though

I think @ikitommi had ideas about this.

SCI is about half my entire build at the moment haha

One reason is that it adds lots of docstrings you might not need. Another reason is that it holds on to functions you might not need. But that's hard to predict in an interpreter, since you don't know what users want to use

Interesting. The second one makes sense. In my case everything read by SCI is located in EDN file(s)

But sci doesn't know before-hand what's in your EDN files

I'm open to ideas of making a more minimal build through some API. The only condition I have is that it should not affect performance of GraalVM binaries like babashka

I think it would make sense to have some kind of optional build size optimization, which is off by default

So that no one is affected, unless they opt-in knowing what they're doing

I think the idea that ikitommi has is more fine-grained. The namespaces.cljc file contains top-level datastructures with all the core namespaces in it. Those should be lifted into a function and then users can do a select-keys or dissoc on those namespaces, and making a top-level value out of that. That should help.

https://github.com/borkdude/sci/issues/357

core namespaces being the namespaces available in SCI?

I've thought about a default setting, but I can't think of a scenario where there's only one default setting that fits all

yes, clojure.core, clojure.string, etc

Checked out the namespaces.cljc file, and I get what you mean now

Basically if you remove a NS / function from there, that would be it?

Well not literally remove, but just filter out

yes, but that should be an option to the user. e.g.:

(sci.core/add-namespace opts 'clojure.core {:exclude [...]}) or `:include

Yeah of course

I wonder if it would work if I took all my EDN files, get all symbols, and just :include all of that. I assume it wouldn't since those symbol might have dependencies not listed in there?

yep, could very well be.

if x depends on y and you're not including y, you're doomed

but with some testing it should be doable to figure it out

btw, the build is still a lot smaller than when you go with self-hosted CLJS which is 8 megabytes or so

at least for https://borkdude.github.io/re-find.web/

Hey I'm not complaining 😛

I'm able to do some amazing things with Sci, which is great

would be great if we could reduce the build some more. <hammock time/>

hi. just prepared malli for dce, users can cut out schemas, from def to defn and one top-level def that can be customized to have the default (all schmas) or an empty registry, which can be customly collected

https://github.com/metosin/malli/blob/master/src/malli/core.cljc#L949-L988

select-keys won’t work here, as Closure tracks down things statically, if you call the function that has everything, everything is added.

but, one can create a new map manually, having just the needed key->value mappings and only those will be in.

what about compile/macro time select-keys?

I think there are two options here. For both: make all the def defns and split them into smaller parts, e.g. clojure-set-bindings, clojure-walk-bindingsetc. Then, the options:

could work.

but the options :): 1. have a global def collecting all int sci.core and create a new entrypoint, like sci.custom that doesn’t have the def, but an api that requires the bindings as parameter 2. have a compiler switch (`:closure-defines` / :jvm-opts) which allow to empty the default registry 3. macro-time select-keys, might work, tested something like this, coudn’t get it to work

I think 1 would be relatively easy

I also like 1. Could you post this into the issue?

https://github.com/borkdude/sci/issues/357

did.

didn’t test the syntax, buf something like:

(require '[sci.custom])
(require '[sci.namepaces :as n])
(require '[clojure.walk :as walk])

(def sci-eval 
  (sci.custom/evaluator 
    {:bindings (merge (n/cloure-core-bindings) 
                      (n/clojure-set-bindings) 
                      {'walk (n/copy-var clojure.walk/walk...)})})

(sci-eval "(int? 1)")
; => true

also, options not to include docstring via options would be great, would allow tiny sci runtimes.

When I added the docstrings, the bundle grew with 200kb. I recently experimented with a closure defines to exclude them but it only mattered 8kb or so. Don't know what's up, needs more attention...

There is a one clojure-based startup in Finland, running clojure in blockchain (real estate smart contracts), poked them to use sci instead.

did the size decrease in clojure.core? Not sure how those are reported.

I just looked at the total size of sci.min.js overall