This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-11
Channels
- # announcements (1)
- # aws (2)
- # beginners (140)
- # boot (67)
- # cider (50)
- # clojure (64)
- # clojure-berlin (1)
- # clojure-conj (1)
- # clojure-france (2)
- # clojure-italy (2)
- # clojure-nl (8)
- # clojure-norway (6)
- # clojure-seattle (1)
- # clojure-spec (81)
- # clojure-sweden (2)
- # clojure-uk (131)
- # clojurescript (147)
- # clojutre (7)
- # cursive (40)
- # datomic (34)
- # editors (5)
- # emacs (7)
- # events (9)
- # figwheel (18)
- # figwheel-main (1)
- # fulcro (2)
- # instaparse (1)
- # jobs (3)
- # leiningen (1)
- # luminus (10)
- # lumo (1)
- # mount (6)
- # off-topic (12)
- # pedestal (4)
- # portkey (7)
- # re-frame (8)
- # reagent (21)
- # reitit (10)
- # ring-swagger (5)
- # shadow-cljs (140)
- # specter (4)
- # tools-deps (53)
- # uncomplicate (1)
Actually, if you are in JVM ClojureScript the function should be able to call Java interop
Right. If the macro ns was defined in a cljc file, would the reader platform conditionals work in a defmacfn
? (:cljs & :clj)
To be honest, I suspect when people want macros in ClojureScript, they may really want āThe whole language always availableā concept spelled out by Paul Graham http://www.paulgraham.com/diff.html (item 9 there).
The chivorcam
approach doesnāt give you that. It gives you a much weaker concept that is close to what we have today, but is really just a little convenient in that you can define a macro right in your ClojureScript source, or right in the REPL.
A lot of cljs is like that. It's deceptively dynamic at dev time while producing this static thing.
Yeah, stepping back and looking at things through a very long term lens: ClojureScript's entire approach is an optimization that caters to the way things are today. You can imagine that in the future, all of this stuff won't be necessary. It may not be that far off. I still recall being surprised seeing a photographic-quality image on a computer screen (25 years ago?), or a near perfect audio in a digital file (15 years ago?). I bet we will have fully dynamic Lisp everywhere ultimately.

In terms of cljs being static as an optimization... Yeah, memory footprint might be less of a worry, more and more. The minification and tree shaking def facilitates runtime performance, so that may always be a boon. Reversible minification would be nice though. But not having a runtime repl... is that a memory optimization or a runtime performance one too?
Well, minification is a runtime performance boost whenever you've gotta push serialized code between workers or clients. But most people don't do that in js
I'm just sayin' go to http://clojurescript.io and it works today. It isn't like you have to wait that long for it.
Yeah, market forces aren't there yet. It's still too much of a cost to ship the runtime.
I'd like to make a mini static blog platform that has a self host repl in it though, that can save itself to github.
And I can just program the site in the site, updating anything, with macros etc, and saving it back to GH
Sorta like these things ~<https://github.com/iamdanfox/ghupdate~> I can't find what I was thinking off, nm
I've got a thing working based on this awesome shadow-cljs example by Matt Huebert here https://github.com/mhuebert/shadow-bootstrap-example
I've got a version of the widget where you can pass in hiccup forms and it produces it in the right pane. So I'm thinking there can just be an edit mode, where you can expand the hiccup content of any given widget on the page. Pretty simple.
It's similar to how https://maria.cloud is built. It's pretty awesome how seamlessly that works with github.
Oh, and a neat perk would be that it still produces static pages, for the view of the website that is not in admin mode (while authed to GH), so viewers of your blog would still be getting a minimal set of artifacts, if any.
Has anybody tried this with a self-hosted cljs compiler? https://github.com/google/closure-compiler-npm
@john that's kinda what lumo is using, except it's just directly google-closure-compiler-js
Yeah, and that's a valid usecase... I suppose if I wanted a github hosted site, where I could generate minified artifacts and save them back to github, that'd be a valid usecase.
Or if I wanted to serialize code between workers, there's an optimization there. But why else would you want to produce new minified artifacts at runtime?
@john Planck also uses it. (See Optimizations under http://planck-repl.org/performance.html)
I think it's more about not needing additional runtimes beyond the one you're targeting
It is fairly easy to use that stuff from ClojureScript. https://github.com/planck-repl/planck/blob/master/planck-cljs/test/planck/closure_test.cljs#L10-L11
I suppose it is not that easy (https://github.com/planck-repl/planck/blob/master/planck-cljs/src/planck/closure.cljs), but you should feel comfortable knowing that it works from self-hosted ClojureScript.
yeah, lumo still bundles itself with a full node runtime for.. reasons. and doesn't seem to have a requirable compilation API from the JS side. Which hopefully will change in the future. Though I haven't had a build script try compiling itself, from lumo
TBH though, I think wasm is the future. I'm researching the semantics now to see how much of MAL can be implemented in raw wast
Maybe that's what Brandon Bloom has been doing, trying to read between the lines of his recent tweets.
Yeah, so I think we may be able to decouple clojure from a particular memory management scheme/runtime by building persistent data structures backed by a fully memory managed (by clojure) pool of fressian objects living on SABs, via a lockfree allocation/reclamation protocol.
Then we may be able to implement a clojure dsl in wasm that operates over SAB fressian pools, without needing a managed memory runtime
And, from what a lot of C++ conference speakers are saying about newer lockfree alloc/free schemes, they can be pretty good
You're still in the JS sandbox, so there's those tradoffs. But pretty soon, there'll be tons of wasm interpreters for the cli for every platform
I mean, wouldn't any interop from your compiled cljs to js and the dom apis only it has access to require going through a binding?
maybe I'm misunderstanding something and this is just for isolated optimized routines
It's a hassle now. Rust is just finishing up something called bindgen that takes care of binding the dom stuff in for you
I could be misremembering but I was under the impression some things needed to be restricted due to safety issues yo uget with a lower level language, but it's not a subject I keep up on super well so I could be conflating things
There's no point in overly restricting access between the two, when the're both in the same js sandbox
I think you'll be able to enforce more sandboxing over the wasm, but it's considered the same sandbox with the same threat model
there's also the whole interop for using the host platform's ecosystem benefit to consider but I can see where the binding might be worth it in some applications because of how little you need to do that
you could do some pretty cool things with a worker that was compiled to wasm from cljs, for example
But don't be surprised if you end up seeing a "posix" wasm module and a bunch of unix utilities ported right into the browser
wrt browsix and your OS moving to the browser... one benefit is package management is already a solved problem by the browser cache.
the browser cache does package management of js files pretty efficiently for users already
wasm is now an official target of the unity engine. Most new games built on it will likely have a web port https://blogs.unity3d.com/2018/08/15/webassembly-is-here/
And wasm seems to be the new hotness for the go and rust communities. I guess go shipped a gc in there, despite some difficulties.
I am having some trouble figuring out how to host some snippet code I wrote with klipse, seems that I do not see cljs.spec.test.alpha
. http://samedhi.github.io/code/2018/09/08/clojure-macro-for-running-clojure-spec-test.html . Thanks you!
Typically you would use,
(ns my-app.thingie
(:require [my-app.doodad :refer [my-function]]))
@priornix this is not possile in CLJS. namespaces are static due to the closure compiler. you can use require
in the REPL dynamically but in files they must be static
Hi, how can I translate this theme.breakpoints.up('md')
to clojurescript?
I managed to access the up function: (-> theme .-breakpoints .-up)
but I am clueless on how to provide the 'md' keyword to it?
Is anyone else using the Oops library? Do you know why I'd be seeing this error?
(oset! (js-obj) :mood "a happy camper")
clojure.lang.ExceptionInfo: Can't change/establish root binding of: *cljs-warnings* with set at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :root-source-info {:source-type :fragment, :source-form (oset! (js-obj) :mood "a happy camper")}, :tag :cljs/analysis-error}
not sure why it should not work in REPL, maybe someone else will have some insight: https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/compiler.clj#L43
Hmm, strange. I'll look into that binding and see if I can figure out what's up. Thank you!!
if I remember correctly, I needed that to add some new warnings into cljs compiler: https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/messages.clj#L40-L65
Interestingly, this works (in the repl):
(set! cljs.analyzer/*cljs-warnings* (merge cljs.analyzer/*cljs-warnings* {:foo true}))
No, I initially started my project with lein new re-frame my-project +10x +cider +re-com +routes +test
Hrm. I suspect that you have the cljs.analyzer
namespace visible in ClojureScript simply because the source ends with .cljc
and it was accidentally compiled.
(That means that, while you can set cljs.analyzer/*cljs-warnings*
, it won't mean much.)
Ah, so my testing of setting that binding wasn't doing what Oops is doing. That makes sense now. I should try from my clj repl.
Yep, that did it:
(set! cljs.analyzer/*cljs-warnings* (merge cljs.analyzer/*cljs-warnings* {:foo true}))
java.lang.IllegalStateException: Can't change/establish root binding of: *cljs-warnings* with set
the idea is to augment *cljs-warnings*
during oset!
macro invocation:
https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/core.clj#L19
with-compiler-context!
is a clojure macro which conditionally generates some code including (set! cljs.analyzer/*cljs-warnings*...)
Yeah, I saw that and it makes sense. I'm just confused as to why I get that error when trying to use oset!
in the repl.
I wonder if piggieback needs that binding to be added: https://github.com/nrepl/piggieback/blob/master/src/cider/piggieback.clj#L303