This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-18
Channels
- # announcements (12)
- # babashka (6)
- # beginners (62)
- # calva (3)
- # cider (41)
- # clerk (5)
- # clojure (192)
- # clojure-bay-area (1)
- # clojure-europe (14)
- # clojure-norway (97)
- # clojure-uk (6)
- # clojuredesign-podcast (4)
- # clojurescript (30)
- # code-reviews (7)
- # cursive (32)
- # datahike (4)
- # datomic (35)
- # docker (8)
- # emacs (8)
- # events (1)
- # fulcro (13)
- # helix (19)
- # hoplon (4)
- # hyperfiddle (37)
- # jobs-discuss (10)
- # membrane (11)
- # missionary (19)
- # off-topic (28)
- # polylith (8)
- # portal (10)
- # practicalli (8)
- # re-frame (31)
- # reitit (6)
- # shadow-cljs (39)
- # timbre (3)
- # vim (1)
- # xtdb (6)
It should work out of the box and importing clj-time.core
shouldnโt be necessary. It would be a bug otherwise. Could you confirm? What behavior do you see when trying to call System/currentTimeMillis
before importing clj-time.core
?
It is unclear to me what solved the issue, I think adding clj-time caused missionary to update and maybe that helped. Unclear. If I run into it again I'll take better notes of the console output -- it was quite weird, it was saying Java.lang System not available and I was like huh you don't know what that is? It was in a #?(:clj ...)
block ... anyway thanks for asking! apologies i don't have more info
This is my working function that takes an id and atom and creates a slider for a key/value pair in the atom.
(e/defn WeightInput [id a]
(div
(ui/range (get @a id 0)
(e/fn [v]
(swap! a assoc id v)))))
I want to style the slider differently if it has a zero value, so I tried this:
(e/defn WeightInput [id a]
(div
(let [current-val (get @a id 0)]
(ui/range current-val
(e/fn [v]
(swap! a assoc id v))
(props {:class (if (zero? current-val) "accent-neutral-500" "accent-orange-400")})))))
Which doesn't work correctly- for one, the sliders don't move independently anymore. What am I missing?instead of derefing the atom you should be providing a reactive value (e/watch in this case). In this case you need to pass the reader (e/watch'd atom) and the writer (the atom itself)
I'm trying to use ratios between client and server
(e/defn TestRatio []
(div
(text "server:" (e/server (/ 1 2))
" client: " (/ 1 2))))
gives me:
server:[TaggedValue: ratio, [#object[Transit$TaggedValue [TaggedValue: n, 1]] #object[Transit$TaggedValue [TaggedValue: n, 2]]]] client: 0.5
is there a good way to configure the reader so a clojure ratio is automatically parsed as a cljs ratio? e.g. I'd like to see
server: 0.5 client: 0.5
cast to float on the server- iirc this is a subtle clojurescript issue , there might be more details if you search
ClojureScript do not support ratios https://www.clojurescript.org/about/differences
> ClojureScript currently only supports integer and floating point literals that map to JavaScript primitives > Ratio, BigDecimal, and BigInteger literals are currently not supported
reviving this thread, has anyone found a good solution for losslessly sharing Ratio-like values between server and client? converting to float worked for previous applications but now I'm needing more precision.
[numerator denominator]
You could set up Transit handlers and have them convert into something like https://www.npmjs.com/package/fraction.js client-side.
in other discoveries, i think the interruptedException via xtdb comes from having some properties on xtdb elements that don't exist -- xtdb has some weird issues if you ask for props that don't exist on every entity, i'm thinking this is the root of the bulk of my concurrency issues lol
xtdb has some weird issues if you ask for props that don't exist on every entitywithin where
clauses this is generally true - that's just how Datalog works - so if you want optional
/`left-join` semantics you can either use pull
, run multiple queries, or use or-join
(which is effectively a subquery) like https://github.com/xtdb/xtdb/blob/b9d98f5006afb81ae1a161f9918546671b69c71b/test/test/xtdb/query_test.clj#L1957-L1960
I wish asking for things that did not exist just returned :key nil
but I suppose it's hard to decisively prove an inexistence? ๐
I have maps with a plethora of keys, I gotta be very careful to not violate an implicate schema it seems. I need an easier way to detect these violations since they creep in over the course of building an app. Is there some level of introspection available to me as an end-user to see what "xtdb thinks" about a particular query or where clause perhaps. Or some in-roads to detecting anomalously shaped data? REPL-driven development plus implicate schema violations throwing a wrench into the engine is programming on extra hard mode in diablo lol.
Hmm, I can sympathise but I don't know of any general advice that can help. Liberal use of the or-join
approach I linked might be worth experimenting with.
In the future I could imagine some sort of :debug? true
option on the query API that could help reason about the execution, showing the counts per clause and the number of false evaluations of predicates in the context of the original query structure. Somewhat similar to https://github.com/xtdb/xtdb/issues/1234
Happy to move the discussion over to #xtdb (apologies for the noise #hyperfiddle ๐๐)
I find myself reaching for a statechart, @dustingetz any chance you have a "Lambda: the Ultimate Statechart" spiel queued up or am I good to go
FSMs i mean, not statecharts
my turn to have an opinion: FSMs suck, too much boilerplate. statecharts are like fsms+behavior trees
i guess i dont get the difference, the distinction appears to be that FSMs dont nest? I would have said they nest
looking forward to seeing what you come up with
interesting read on the topic https://eli.thegreenplace.net/2009/08/29/co-routines-as-an-alternative-to-state-machines/
hypothesis: FSMs and FRP are isomorphic. Don't know if true
Here's an example. FSM or cycle + if statement?
rust's async/await feature is built on generators which are coroutines, and compiles to a state machine so there must be a relation there
not sure what you mean by fsms nesting, but statecharts can bubble up events so you don't need to duplicate event handlers, and have parallel states
Whatโs the current state of the art for whipping up electric apps, are folks primarily forking the starter app?
I hope so, remember we update it periodically