This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-22
Channels
- # announcements (5)
- # aws (38)
- # aws-lambda (21)
- # babashka (45)
- # beginners (87)
- # boot (1)
- # calva (32)
- # cider (23)
- # clara (7)
- # clj-kondo (41)
- # cljs-dev (29)
- # clojure (145)
- # clojure-europe (6)
- # clojure-italy (12)
- # clojure-nl (4)
- # clojure-spec (39)
- # clojure-uk (45)
- # clojurescript (171)
- # copenhagen-clojurians (4)
- # cursive (14)
- # datomic (48)
- # docker (6)
- # figwheel-main (2)
- # fulcro (54)
- # jackdaw (1)
- # jobs (1)
- # kaocha (3)
- # leiningen (7)
- # luminus (6)
- # malli (2)
- # off-topic (51)
- # pathom (8)
- # quil (20)
- # re-frame (14)
- # reagent (1)
- # reitit (2)
- # remote-jobs (1)
- # shadow-cljs (39)
- # tools-deps (1)
- # vim (12)
- # xtdb (5)
Maybe some people here?
alright thank you Thomas, if anyone has more info on missing pieces in wasm, please tag me
Curious, how would you say the clojurescript scene has changed in the last ~2 years? In terms of dominant libraries, techniques etc
hmmm, I’d say nothing changed, majority is still using Reagent and re-frame
There is also https://fulcro.fulcrologic.com/ which should be a lot more appealing than it was 2 years ago, particularly if you want to build full stack applications with a Datomic back end.
What about React hooks? How good of a decision is it (not) to use them? Particularly when they're all the rage in the wider js world
https://github.com/Lokeh/hx has a bit on using hooks (particularly at https://github.com/Lokeh/hx/blob/master/docs/why-not-reagent.md)
:thumbsup: I re-read it now. Was aware of it; I'm just not sure if people are using it to build apps, how it compares in practice to a re-frame experience, etc
I recall some discussions about how hooks and some of the other recent react features essentially replicate already existing functionality from reagent. The only one I could find again was https://news.ycombinator.com/item?id=21772910, which kind of sums up those conversations as I remember them.
heya,
are there any breaking changes one should be aware of when updating to 1.10.59
and using cljs.spec.alpha
?
I'm updating a project's cljs 1.10.520
to `1.10.597` , and my optimised build now fails when loading something spec related
| TypeError: Cannot read property 'prototype' of ...
V
$APP.$cljs$spec$alpha$t_cljs$0spec$0alpha62946$$.prototype.$cljs$spec$alpha$Spec$gen_STAR_$arity$4$ = $JSCompiler_unstubMethod$$(6, function($_$jscomp$256$$, $overrides$jscomp$11$$, $path$jscomp$62$$, $rmap$jscomp$11$$) {
return $APP.$cljs$core$truth_$$(this.$gfn$) ? this.$gfn$.$cljs$core$IFn$_invoke$arity$0$ ? this.$gfn$.$cljs$core$IFn$_invoke$arity$0$() : this.$gfn$.call(null) : $APP.$cljs$spec$alpha$re_gen$$(this.$re$, $overrides$jscomp$11$$, $path$jscomp$62$$, $rmap$jscomp$11$$, $APP.$cljs$spec$alpha$op_describe$$(this.$re$));
});
(alexmiller was kind enough to direct me here instead of #clojure-spec since cljs.spec.alpha has a different imp than spec.alpha)stepping through the exceptions showed this particular bit as being the one that yielded the final exceptions
I haven't traced these symbols to see where they are used yet
I think we mean the same thing, insofar as I have to go figure out how these symbols trace back to my source
I haven't done that yet but it's next on the docket, now that I know there isn't something obvious I should be following to update
also search the source for other references to $cljs$spec$alpha$t_cljs$0spec$0alpha62946$$
will do, thank you for the hint
I was working on this a bit more today
I did identify the bit of code that does it by using sourcemaps
it seems related to reify, but it's in the source for cljs.spec
I think regex-spec-impl
, let me double check
I've been doing release builds all day and trying variations of things to see if I could narrow it down... must have done some 40 at least
what do you get when you look for $cljs$spec$alpha$t_cljs$0spec$0alpha62946$$
in your output?
one second, let me just give you the findings I already have
I think I've finally hit a way to make it not happen
• will not error if there are only s/def
• will error if there are s/assert or s/fdef
• doesn't matter if s/check-asserts was used, or what the value was
• only takes a simple assert to fail e.g. (s/def ::str string?)(s/assert ::str "abc")
• will error if the assert is in a lazy module
• will not error if the assert is in the initial non-lazy module
• once there is an assert in the initial non-lazy module, having asserts in the non-lazy modules doesn't seem to cause errors
that last bit was what I just figured out
will uncomment all the other asserts to see if it still holds true outside the sample code I was using
frankly the code in spec scares me ... the macro driven nature makes it extremely hard to follow
what was missing?
I managed to get into a bad state again, I think after I uncommented fdefs....
I'm guessing both assert and fdef need to be in the entry module
can verify it doesn't even need the s/def, (s/assert string? "abc")
is enough
ok the problem seems to be that the closure compiler recognizes the "class" created by reify
in the codebase I am on, adding this to the entry module makes everything else work ok
(s/assert boolean? true)
(s/fdef boolean? :ret boolean?)
yeah I imagined it'd pull it to the entry
I'll make an issue
no, output-wrapper made that random weird npm lib work ok
it's pretty easy to work around, just very surprising
so you can imagine a repro without spec?
well ... I knew about the issue in other contexts. that it affects method motion is news to me 😛
I don't think I understand reify well enough to repro with it
does the cljs issue tracker issue accept shadow-cljs repros?
funny enough this wouldn't happen with https://ask.clojure.org/index.php/8879/cljs-should-macros-support-lifting-vars-to-the-ns-level 😛
if it helps, this project has a bunch of lazy modules, not just one
(ns test.main
(:require
[cljs.spec.alpha :as s]))
(s/def ::foo pos-int?)
(defn init []
(js/console.log "test.main init"))
(ns test.mod-a
(:require
[cljs.spec.alpha :as s]
[test.main :as main]))
(defn init []
(js/console.log "mod-a init")
(s/assert ::main/foo -1))
;; shadow-cljs configuration
{:source-paths
["src/dev"
"src/main"
"src/test"]
:dependencies
[]
:dev-http
{9300 "public"}
:builds
{:test
{:target :browser
:modules
{:shared {:entries []}
:main {:init-fn test.main/init
:depends-on #{:shared}}
:mod-a {:init-fn test.mod-a/init
:depends-on #{:shared :main}}}}}}
<script src="js/shared.js"></script>
<script src="js/main.js"></script>
<script src="js/mod-a.js"></script>
don't really need the "shared" module but CLJS has the implicit cljs_base module so need 3 for testing
if you feel like reproducing with just cljs.main and reporting the CLJS Jira go ahead
I'm wrecked from looking for this all afternoon, but I think I'll try to repro and report tomorrow morning, or afternoon
haven't used cljs main either, and that sort of thing is usually a bit hard on windows
but it might work out with wsl
thanks for all the help figuring this out
well hard work isn't always enough
ok ... I reproduced it with pure CLJS ... can't sleep anyways when thinking about this
this sounds like a tough one to fix
nice minimal code too
can you link the issue here if you're opening it?
would be great if you open the issue. I don't really have the bandwidth to pursue this further.
Will do
here it is
feel free to edit any innacuracies
will ping David about it as well
@dnolen in regards to the spec regression on 1.10 that I mentioned a couple of days ago, @thheller looked into it with me and we found it's related to reify
across modules. Opened issue for it: https://clojure.atlassian.net/browse/CLJS-3207
@filipematossilva not aware of anything - there were some fixes in the last release but nobody else reported a regression yet - just other bugs / missing things
coolio, thank you for the info
I'll try to narrow it down and see if it's something silly we're doing or if there's some regression
@filipematossilva thanks please file a ticket if you can isolate a regression
Have you filled out the 2020 State of Clojure Community Survey yet? It's a great source of info in understanding the community, and we'd welcome your participation if you have a few minutes. https://surveymonkey.com/r/2020clojure
Is ISeq implemented for JS objects, arrays, and ES6 sets? I’m wondering if it would be possible to keep immutability through functions rather than the data structures being immutable themselves. The question mainly comes from concern about performance in certain situations like creative coding and interactive graphics. I was told that CLJS’s immutable data structures can be too slow in these cases which led me to wonder if we could just implement the ISeq functions for JS data structures purely
This of course wouldn’t defend again third-party code from mutating them, but it would be a step.
I think iteration is about 2-3x slower in general, so it really depends on what is slow for you.
all cljs data structures are necessarily javascript data structures underneath. and cljs already has an answer to "discard immutability for speed" (transients) that my guess is is pretty well tuned
what I'm saying is if you find some big wins see if you can get it back into the cljs transients code 🙂
Again, this is just an area I’m interested coding with CLJS in but have been warned against it for performance reasons, including with the use of transients
But I don’t have personal experience with this problem yet, nor do I know if said others know about cljs-bean
It is definitely easier for some kinds of code to squeeze out the best performance of the language you can if you use mutable data structures. I do not know for sure, but it might be impossible (or at least highly impractical) to achieve maximum performance in some applications using only immutable data structures. That said, you can often achieve good enough performance using immutable data, when you aren't writing a game engine or the inner loop of some heavy number crunching code.
If you are working on code that takes 90% or more of the time and trying to optimize it, then I'm not sure JS is even the right language.
IMO with enough care you can always write cljs code which will transpile into no-overhead js similar to hand-written js (e.g. using a lot of interop and native js arrays and objects) - it just won’t be idiomatic clojure code so I’m pretty confident in using cljs in all scenarios where js would be used, I keep using cljs in idiomatic way and later when I identify performance issues, I rewrite hot paths into non-idiomatic fast cljs or in the worst case I have always escape hatch to rewrite such hot code in js directly and use it from rest of my cljs codebase
It is difficult for us to know how nuanced and thoughtful the suggestion to avoid immutable data was 🙂
yeah using native js arrays seems like a good trick when you need it
cljs.user=> (simple-benchmark [arr #js [1 2 3 4 5 6 7 8]] (areduce arr i ret 0 (+ ret (aget arr i))) 500000000)
[arr #object[cljs.tagged-literals.JSValue]], (areduce arr i ret 0 (+ ret (aget arr i))), 500000000 runs, 3530 msecs
nil
cljs.user=> (simple-benchmark [arr [1 2 3 4 5 6 7 8]] (reduce + 0 arr) 500000000)
[arr [1 2 3 4 5 6 7 8]], (reduce + 0 arr), 500000000 runs, 38302 msecs
I have met some developers who worry about performance when it isn't crucial.
where I see a problem is when my idiomatic cljs code needs to interact heavily with rest of js, that needs marshalling between js native data structures and cljs data structures - it is annoying/error prone and could lead to performance issues
@mruzekw note nothing is stopping you from writing ClojureScript around JS native types
transducers perform reasonably well on arrays - in striking distance of handwritten loops (because effectively that's what it is anyway)
people have written games and interactive applications that perform reasonably w/o bothering with this stuff
Hmm, alright. Well I’ll have to look further into their claims and what they were working on
if you know what you are going to do and you know it requires primitive arrays and hand written loops you can do that is all I'm saying
if all your serious stuff is in WebGL/shaders then ClojureScript probably won't be much of bottleneck
if you'll be shuttling buffers around so you can't use ClojureScript data structures here anyway
@mruzekw I’m just in the process of porting react-three-fiber examples to cljs, so far it looks plausible (and the code does a lot of interaction with three.js) - at least the dev experience will be on par with writing js+jsx - haven’t done any performance comparisons yet https://github.com/binaryage/cljs-react-three-fiber
he is an example how the actual demo code looks like: https://github.com/binaryage/cljs-react-three-fiber/blob/master/examples/src/app/react_three_fiber/examples/demos/refraction.cljs
I tend to hide all interop-y stuff under helpers namespace and the main code reads quite well, so even Cursive does not complain 🙂
I’m also a musician, so I think it would be cool to hook up MIDI or live sound to a music visualizer
@dnolen react-three-fiber is pretty recent project, they build on the fact that you can write custom reconcilier for react, so you can manage other structures in react-way, not only DOM
@mruzekw if you want to learn it you could take some demos and help me port them - the scaffold is in place, it should be just a matter of rewriting their js code into nice cljs 🙂
I whipped up a quick example of using react-three-fiber with helix, too 😄 https://gist.github.com/Lokeh/c0fd5d8df772412be79a034d627f8ff0
@dnolen in regards to the spec regression on 1.10 that I mentioned a couple of days ago, @thheller looked into it with me and we found it's related to reify
across modules. Opened issue for it: https://clojure.atlassian.net/browse/CLJS-3207