This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-16
Channels
- # announcements (3)
- # babashka (25)
- # beginners (71)
- # calva (18)
- # clj-kondo (52)
- # cljs-dev (94)
- # cljsrn (12)
- # clojure (33)
- # clojure-europe (52)
- # clojure-nl (2)
- # clojure-uk (27)
- # clojurescript (18)
- # clojureverse-ops (4)
- # datomic (64)
- # deps-new (27)
- # depstar (5)
- # events (5)
- # fulcro (5)
- # graalvm (12)
- # graalvm-mobile (82)
- # helix (2)
- # introduce-yourself (1)
- # juxt (5)
- # lsp (10)
- # malli (7)
- # missionary (1)
- # off-topic (41)
- # pathom (69)
- # pedestal (6)
- # re-frame (4)
- # reagent (8)
- # releases (9)
- # remote-jobs (8)
- # shadow-cljs (3)
- # sql (46)
- # tools-deps (44)
- # uncomplicate (1)
- # vim (83)
@dnolen If you care, I think I figured out the problem. Its that the macro expansion itself doesn't use the eval-fn
you give it and expects that eval-fn
modified the global environment.
That part doesn't seem inherently true to me. Is there something special about the clojurescript compiler that prevents it from calling eval?
the point of self-hosted is just to have a nearly fully compatible thing that can run in JavaScript
That's also fair, but then I would recommend putting that in the docs. (Unless I missed it?)
I'm looking here: http://cljs.github.io/api/cljs.js/
(To be fair, I very well could have missed that self-hosted is never recommended. 🙂 )
you are willing to figure it out on your own, you're building some kind of online tooling, some kind of Node.js thing etc. etc.
we should probably maintain our thing to have more control - but the amount of time in the day on such a large project is limited
I guess there is this: https://clojurescript.org/guides/self-hosting
Anyway, no big deal. I'll probably just modify the analyzer to run via eval rather than running directly.
> "what the output is so big, this is is no good" etc. Oh, my artifact is 1-2 MB gzipped, which for a normal webpage is huge, but for an ide is okay. 🙂
> that said it would be cool to see external efforts to document self-hosted Oh don't worry, I will. 🙂 (At least if its okay with you. I'd like to not step on people's feet.)
nothing is stopping you from monkey-patching something in the compiler to get the behavior you want
> the other thing is of course JavaScript and ClojureScript are both super hackable
I noticed. ^.^ (I've actually already done that to make the eval-fn
and load-fn
both take callbacks.
But ya, right now this how I'm requiring the custom tweeks: https://github.com/LeifAndersen/interactive-syntax-clojure/blob/main/deps.edn#L3-L4
If there's a better way than literally pushing a 'slightly patched' build to a github repo I'm always ears. 🙂
(Not super experienced with state of the art java build environments. I'm more familiar with macro expanders and embedded systems. 😉 )
like a make a project that depends on ClojureScript, take the parts of js.cljs
that make sense to you and do it different
all the choices about asychrony etc. are made there - the rest of the compiler is fully generic free of I/O concerns
to simplify maintaining a thing - that's how I would do it - no conflicts in js.cljs
etc.
@plexus welp it turns out it already was possible to do what you wanted just writing a macro that emits ns
- mind checking if this satisfies your requirements - if so just going to revert your changes
if it does satisfy then after the revert we'll cut a release - and we can do a post that explains it always possible - and this will get rid of these nasty issues
also the parse-ns
approach would be problematic for self-hosted - and writing macros that emit ns
should work in all situations
> self-hosted is ~300k gzipped I get more like 800kb gzipped like numbers, ~8mb unzipped, e.g. here: https://borkdude.github.io/re-find.web/
I could do a more proper analysis because this also includes cljs.spec, and a bunch of core specs, so it might be slightly less
self-host is :simple
only so it'll grow very quickly once you add stuff like reagent, re-frame, cljs.pprint, etc. just bare-bones cljs.core isn't that large on its own
https://github.com/clojure/clojurescript/pull/99 - all tests passing, all code reverted, but the original 3276 test still passes
don't forget to count the :bootstrap
output though. regular CLJS will at least contain the analyzer data for cljs.core
directly in the main build while shadow-cljs will keep that all separate and loaded via transit
@U05224H0W Where in the report can I find this?
I may not have correctly set this project up with shadow. I didn't know how to port the cljsjs deps to npm, could not find the codemirror addons.
This is the branch: https://github.com/borkdude/re-find.web/tree/shadow
the report doesn't mention :bootstrap
stuff since its a separate build. guess you can just look at the files 😉
https://code.thheller.com/blog/shadow-cljs/2017/10/14/bootstrap-support.html this I mean. you'll need that for any kind of self-hosted stuff
I see. I was hoping to port this project with minimal changes, but it's a bit more work. Perhaps it's better to just start from scratch and evaluate a trivial expression, without all the UI/codemirror stuff
only the bootstrap/init stuff is new and the load-fn it provides. everything else should be the same
ok there was one thing missing, I changed it so ns always just merges info - this probably in the end closer to the semantics of Clojure
something like this was always necessary for REPLs to behave in the expected way but it was done in a more a roundabout way and only for REPLs