This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-13
Channels
- # babashka (10)
- # beginners (27)
- # calva (91)
- # cestmeetup (3)
- # cider (27)
- # clj-kondo (12)
- # cljs-dev (4)
- # clojars (13)
- # clojure (35)
- # clojure-europe (30)
- # clojure-france (3)
- # clojure-houston (1)
- # clojure-nl (11)
- # clojure-norway (29)
- # clojure-spec (23)
- # clojure-sweden (5)
- # clojure-uk (128)
- # clojurescript (69)
- # conjure (44)
- # core-async (27)
- # cursive (13)
- # emacs (9)
- # events (3)
- # fulcro (52)
- # graphql (4)
- # jobs (2)
- # jobs-discuss (46)
- # kaocha (4)
- # luminus (12)
- # nrepl (10)
- # off-topic (29)
- # re-frame (17)
- # reitit (20)
- # remote-jobs (4)
- # rewrite-clj (1)
- # ring (4)
- # rum (13)
- # shadow-cljs (40)
- # sql (1)
- # xtdb (1)
Q: I’m trying to validate a long value, a datomic :db/id decoded via transit. some of the values print at #object[Long] or Long { low_: 329, high_: 16175104 }. I presume this means that they are decoded into goog.math.Long. I can’t find a predicate in the goog.math api to validate these values. Any suggestions?
I would be happy with just a type check. can’t work out how to do that in Closure either
It seems like I could use :modules in my project file to expose an entire namespace as a module, is that right?
what are you trying to do? export a namespace for a JS library to consume or something?
to directly answer your question - there's no built in way to export a namespace - you use ^:export
to do this per definition
however, you have macros and a programmable build system - you could probably sort it out if you really want that convenience
here's what I ended up doing: https://github.com/littleredcomputer/sicmutils/blob/a07c349f4fee40fbe18f5c51f9ed830f2d2d4ca7/src/sicmutils/value.cljc#L164
I have a separate multimethod eq
that can handle equality between goog.math.{Long, Integer}
, js/BigInt
and js/Number
(and the ratios and BigDecimal I need to add next), and I bail out to that from the -equiv
implementation if the second arg is not a js/Number
(extend-protocol IEquiv
number
(-equiv [this other]
(cond (core-number? other) (identical? this other)
(number? other) (eq this other)
:else false)))
bailing out full-stop without the core-number?
check is a big performance hit, as you'd expect.
I wonder, what is the reason behind:
ExceptionInfo: failed compiling constant: 1/4; clojure.lang.Ratio is not a valid ClojureScript constant.
precision?1/4 should be exactly representable as base 2
the clojure ratio type is not a normal number - it can hold rationals that can't be represented as floats without losing precision, what's the context of that error?
most of the time I replace (/ x y)
with (/ x (double y))
to avoid constructing rationals
Clojure:
user=> 1/4
1/4
ClojureScript:
cljs.user> 1/4
------ REPL Error while processing ---------------------------------------------
1/4
Error in phase :compilation
I’m pretty sure ClojureScript treats all number types as JS number
, so it doesn’t have explicit support for rationals like Clojure does
not sure why the literal isn’t supported (and just returns a JS number
), but there you go 🙂
Perhaps owing to the reader differences, you will get a number
for fraction literals in self-hosted ClojureScript
There is this old ticket: https://clojure.atlassian.net/browse/CLJS-555
noisesmith, context - is a silent :compilation phase error in older version of shadow-cljs, because I had a 1/4
pasted from repl in some form in cljc file.
https://clojurians.slack.com/archives/C6N245JGG/p1597334746145300
aha, I missed (and found it surprising) that it would blow up like that for a literal
the (maybe) weird thing is, cljs main compiles
(ns foo.bar)
1/4
just fine, but throws on
(ns foo.bar)
[1/4]
looks like the problem is well explained by prior comments, it seems reasonable to ask that cljs just generate the appropriate float when reading that literal
right, but a power of two divisor should not be a problem...
that's literally moving the decimal point in the float representation that js uses
right - what I'm trying to say is we proved that precision isn't the problem
it's a type error, in the reader
it's a broken code path
my hunch is that (ns foo.bar) 1/4
compiles fine because there's no reason to compile the rational - you know a-priori that it's garbage
well, [1/4] is a garbage too, although nested, so immediate handling function might not see entire form, and that it is top level one
right - top level handling has special cases, but once again it's just a hunch on my part
you could also try (ns foo.bar) (do 1/4)
the plot thickens
cljs.user=> (do 1/4 :OK)
:OK
constants are just discarded in "statements" (ie. the result is not used). so top level and in do like that is the same.
cljs main -compile
and -eval
worked different for me today for 1/4
and [1/4]
, while I was chasing exact behavior.
let me send the link to the version whre support for this literal dropped
this was the change, to defer to tools.reader
ratio-pattern
lives in reader.impl.commons
now, and I don't think the normal codepath includes match-ratio
anymore
but you can see the old behavior here
it might be because it doesn't make any practical different in this example. no code is waiting on the browser to close.
That's true, but still we should resolve it so that Promise is not wrapped by chan.
in the first screenshot (JS example) there is an await
there.
maybe it is a typo in the http://clojurescript.org guide :thinking_face:
It's a typo.