This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-03
Channels
- # announcements (8)
- # aws (2)
- # babashka (16)
- # beginners (173)
- # calva (13)
- # cider (4)
- # cljfx (6)
- # cljs-dev (108)
- # clojure (63)
- # clojure-australia (2)
- # clojure-dev (10)
- # clojure-europe (73)
- # clojure-italy (8)
- # clojure-nl (4)
- # clojure-norway (5)
- # clojure-uk (4)
- # clojurescript (49)
- # clojureverse-ops (4)
- # community-development (3)
- # core-async (23)
- # cursive (3)
- # data-science (5)
- # datomic (25)
- # emacs (3)
- # events (1)
- # fulcro (13)
- # helix (5)
- # introduce-yourself (1)
- # lein-figwheel (1)
- # lsp (36)
- # malli (1)
- # meander (2)
- # membrane (4)
- # music (8)
- # nextjournal (51)
- # off-topic (47)
- # other-languages (5)
- # pathom (31)
- # pedestal (5)
- # planck (14)
- # polylith (5)
- # portal (1)
- # re-frame (30)
- # react (2)
- # reagent (24)
- # releases (1)
- # rewrite-clj (18)
- # ring (9)
- # sci (33)
- # shadow-cljs (49)
- # testing (3)
- # tools-build (21)
- # tools-deps (29)
- # vim (19)
- # web-security (1)
- # xtdb (12)
It's unusual to need to have worry about this unless you’re writing a wrapper of some kind
js
is a kind of taint - signaling nothing can be known so all users of the thing via interop should also be tainted
Thanks for the reply! To add detail, in my case, I'm writing wrapper functions around the WebRTC API in the browser, and I need to support advanced compilation. It's interop on built-in types. I had ^js/RTCRtpTransceiver
, but it still created a warning and did not generate the extern. I had to use ^RTCRtpTransceiver
instead. Why the difference? Is there something different about browser API types?
(defn set-codec-preferences
[^RTCRtpTransceiver transceiver
codecs]
(.setCodecPreferences transceiver codecs))
the closure compiler already has externs for webrtc by default. you sure you need them? https://github.com/google/closure-compiler/blob/master/externs/browser/w3c_rtc.js
Apparently I also need to update my ClojureScript version. I'm on 1.10.773. The extern for setCodecPreferences was added in the Closure Compiler more recently. Nonetheless, I'm still trying to figure out why having js/
would prevent the automatic extern inference and removing it allows automatic extern inference to work fine.
OK, I had to share this…
I’m looking at parse-long
and parse-double
. The first one was simple enough:
(and (re-matches #"[+-]?\d+" s) (js/parseInt s))
So then I looked at the second one, and thought that I’d just use a regex like last time. A little more complicated, because the decimal point and fractional parts are optional, there’s scientific notation, etc. But it turns out that https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#valueOf-java.lang.String-…
To avoid calling this method on an invalid string and having a `NumberFormatException` be thrown, the regular expression below can be used to screen the input string:
final String Digits = "(\\p{Digit}+)";
final String HexDigits = "(\\p{XDigit}+)";
// an exponent is 'e' or 'E' followed by an optionally
// signed decimal integer.
final String Exp = "[eE][+-]?"+Digits;
final String fpRegex =
("[\\x00-\\x20]*"+ // Optional leading "whitespace"
"[+-]?(" + // Optional sign character
"NaN|" + // "NaN" string
"Infinity|" + // "Infinity" string
// A decimal floating-point string representing a finite positive
// number without a leading sign has at most five basic pieces:
// Digits . Digits ExponentPart FloatTypeSuffix
//
// Since this method allows integer-only strings as input
// in addition to strings of floating-point literals, the
// two sub-patterns below are simplifications of the grammar
// productions from section 3.10.2 of
// The Java Language Specification.
// Digits ._opt Digits_opt ExponentPart_opt FloatTypeSuffix_opt
"((("+Digits+"(\\.)?("+Digits+"?)("+Exp+")?)|"+
// . Digits ExponentPart_opt FloatTypeSuffix_opt
"(\\.("+Digits+")("+Exp+")?)|"+
// Hexadecimal strings
"((" +
// 0[xX] HexDigits ._opt BinaryExponent FloatTypeSuffix_opt
"(0[xX]" + HexDigits + "(\\.)?)|" +
// 0[xX] HexDigits_opt . HexDigits BinaryExponent FloatTypeSuffix_opt
"(0[xX]" + HexDigits + "?(\\.)" + HexDigits + ")" +
")[pP][+-]?" + Digits + "))" +
"[fFdD]?))" +
"[\\x00-\\x20]*");// Optional trailing "whitespace"
if (Pattern.matches(fpRegex, myString))
Double.valueOf(myString); // Will not throw NumberFormatException
else {
// Perform suitable alternative action
}
https://github.com/clojure/data.json/blob/master/src/main/clojure/clojure/data/json.clj#L130
If you really want to know, I went with:
#"[\x00-\x20]*[+-]?(Infinity|((\d+\.?\d*|\.\d+)([eE][+-]?\d+)?)[dDfF]?)[\x00-\x20]*"
I check for NaN
first, because it has to be dealt with separately (it will explicitly return ##NaN
while many other numbers parsed in JS will also return NaN and instead we need to return nil
)
What’s up @U4YGF4NGM? That’s eminently readable!
I saw that Alex is asking for people to try the beta on projects. Is it possible to run canary or coal-mine (forgot exactly which) but holding the cljs version constant and instead using the new beta? And if so, would that be helpful?
yes probably - been meaning to look at canary (to move it to GH CI) but simply haven't had time
did you ever bump the data.json version cljs uses?
well, we made it a lot faster :)
and fixed some bugs
2.4.0 is latest
@alexmiller should I bump transit too?
no, it doesn't, but probably would be good to bump transit if it's lagging
we are near to releasing a new transit-java and transit-clj, although I don't think the fix that will be in there has any impact on cljs's use
what was the issue - transit-js definitely ported over bits of the Java in terms of the big picture
transit-java determined key stringability based on the value of the key rather than the xform of the key.
from testing, I think this was not an issue in transit-cljs
correct
I looked briefly at the CLJS impl and it seemed that the specific symbol + meta problem wouldn't cause an error because (my memory is foggy here) on strings are stringable (?)
It was a while ago so I may be wrong
@fogus well I think did the original metadata support many many years ago on transit-clj and transit-cljs - probably I just missed this issue on the the clj side
it's complicated :)
each type of thing might need to be handled differently, i.e. images in React Native vs. CSS for web stuff
I believe it’s fairly popular to need to bring in these non-js assets with npm deps though. So I’d imagine this should be a fairly common problem space.
so then if you js/require
after your ns declaration they would get lifted - but in this namespace only
That approach makes sense to me certainly for this. Sounds promising! Basically it gives a way to add to the generated js.
so I think to avoid a compiler pass carnival this can be restricted to the assets use case
Yeah, it may be better to constrain. So this is still metadata you’d put on the ns
form, which would allow you to have these js/require
’s after the ns
form for the specified asset types?
because the target directory has the JS we have to change all the img paths to point to the right locations
ought it be a string instead of a kw to allow file patterns that aren't valid kws? e.g. #{".foo.bar"}
I think generally, I agree with the idea of not closing doors and needing to be more specific in the metadata.
@thheller I don't have much love for it either - but this one of the most often asked questions - and everyone has to workaround it
Yeah, I also wasn’t a fan of requiting assets from the JS-ecosystem. It just seems like libs are nearly forcing you into it.
re: path problems: I’d think the require from CLJS (in an npm case) would be something more like (js/require "npm-lib-dep/css/styles.css")
where it’d come from something like the installed node_modules, but now that I say this, I’m really only familiar with doing these things in the es6 style import
, so maybe I’m completely off.
@thheller just wondering, does the above import 'foo.css'
stuff already work with shadow's target :esm
?
no, since its not standard ESM functionality. if you post process with webpack it'll work yes