This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-23
Channels
- # announcements (66)
- # babashka (41)
- # beginners (93)
- # calva (10)
- # cider (2)
- # clj-kondo (112)
- # cljs-dev (6)
- # cljsrn (1)
- # clojure (44)
- # clojure-dev (10)
- # clojure-europe (35)
- # clojure-italy (15)
- # clojure-nl (3)
- # clojure-uk (2)
- # clojurescript (38)
- # conjure (1)
- # datalevin (1)
- # datomic (16)
- # deps-new (4)
- # events (7)
- # figwheel-main (1)
- # fulcro (59)
- # graalvm (21)
- # integrant (3)
- # introduce-yourself (8)
- # jobs-discuss (2)
- # malli (23)
- # membrane (11)
- # membrane-term (2)
- # missionary (17)
- # off-topic (7)
- # pathom (23)
- # pedestal (6)
- # polylith (7)
- # portal (25)
- # releases (1)
- # remote-jobs (3)
- # reveal (5)
- # shadow-cljs (43)
- # spacemacs (7)
- # sql (18)
- # tools-deps (33)
- # vim (10)
- # xtdb (36)
I just published the first release of sweet-array https://github.com/athos/sweet-array, an array manipulation library for Clojure with sweet array type notation and more safety by static types! • Defines a concise and intuitive array type notation, and provides a generic array constructor which can be used for any types and dimensionalities • Automatically inserts type hints for arrays based on the results of type inference, which reduces the cases where users have to add type hints manually
this is cool! any particular reason you didn’t wrap/re-export alength
?
this seems very useful for when you want better utilities for working with arrays but you might not want to pull in all the dependencies of dtype-next
- cool stuff!
@UEENNMX0T Hi, thanks! The only thing we can do for that is type checking, so I didn’t give it much priority. But from the completeness point of view, it might be good to add it.
@UFTRLDZEW Yeah, dtype-next
is powerful and useful but could sometimes be overkill. This library can be used for little Java interop things like varargs method calls.
https://github.com/clojure/core.async 1.5.640 is now available (all fixes in both CLJ and CLJS): • https://clojure.atlassian.net/browse/ASYNC-204 On put to closed channel, commit handler to allow pending alt ops to be cleaned up • https://clojure.atlassian.net/browse/ASYNC-235 Fix ioc-macros/return-chan registers a callback with incorrect arity • https://clojure.atlassian.net/browse/ASYNC-144 Tweak docstring in pipeline-async • https://clojure.atlassian.net/browse/ASYNC-238 Fix a/map with empty chan vector hangs Several of these are important bug fixes and I would recommend updating.
https://github.com/clojure/spec.alpha 0.3.214 is now available: • https://clojure.atlassian.net/browse/CLJ-2606 Add support to transform trailing maps on instrumented functions into kvs (really only relevant for 1.11.0-alpha1+)
(same change applied to spec 2 as well, but no releases there)
Clojure https://clojure.org/releases/devchangelog#v1.11.0-alpha3 is now available: • https://clojure.atlassian.net/browse/CLJ-2667 Add functions to parse a single long/double/uuid/boolean from a string • https://clojure.atlassian.net/browse/CLJ-2668 Add NaN? and infinite? predicates • https://clojure.atlassian.net/browse/CLJ-1925 Add random-uuid • https://clojure.atlassian.net/browse/CLJ-2664 Add clojure.java.math namespace, wrappers for java.lang.Math • https://clojure.atlassian.net/browse/CLJ-2666 Make Clojure Java API javadoc text match the example • https://clojure.atlassian.net/browse/CLJ-1360 Update clojure.string/split docstring regarding trailing empty parts • https://clojure.atlassian.net/browse/CLJ-2249 Clarify clojure.core/get docstring regarding sets, strings, arrays, ILookup • https://clojure.atlassian.net/browse/CLJ-2488 Add definition to reify docstring • https://clojure.atlassian.net/browse/CLJ-1808 map-invert should use reduce-kv and transient • https://clojure.atlassian.net/browse/CLJ-2065 Support IKVReduce on SubVector • Update dep to spec.alpha (0.3.214)
We'll have it in QA by end of day. Our next backend production build will be next week 🙂
(a bunch of folks are off this week due to Thanksgiving)
Docs for new things: • https://clojure.github.io/clojure/branch-master/clojure.java.math-api.html namespace (many fns) • https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/parse-long • https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/parse-double • https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/parse-boolean • https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/parse-uuid • https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/NaN? • https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/infinite? • https://clojure.github.io/clojure/branch-master/clojure.core-api.html#clojure.core/random-uuid
Looking forward to retiring some of our conversion/parsing functions in favor of these new built-in ones!
The parse functions are right on time for this year's Advent of Code 💯
@U8MJBRSR5 How do those make it easier? You can mostly just call the parse*
JVM functions. A bit more effort since you'd need try
/`catch` but it doesn't make anything completely new possible, just more convenient.
Same as what you mentioned, I am looking forward to retire https://github.com/green-coder/advent-of-code-2020/blob/master/src/aoc/util.clj#L22-L29.
That function isn't the same at all:
user=> (parse-long "\n 18 15 \n")
nil
user=> (parse-long "\n \"18\" 15 \n")
nil
user=> (require '[clojure.edn :as edn])
nil
user=> (edn/read-string "\n 18 15 \n")
18
user=> (edn/read-string "\n \"18\" 15 \n")
"18"
user=>
Yes, I know.
Some functions in the math namespace result in reflection warnings:
Loading /Users/ikoszo/.m2/repository/org/clojure/clojure/1.11.0-alpha3/clojure-1.11.0-alpha3.jar!/clojure/java/math.clj...
Reflection warning, /Users/ikoszo/.m2/repository/org/clojure/clojure/1.11.0-alpha3/clojure-1.11.0-alpha3.jar!/clojure/java/math.clj:362:3 - call to static method abs on java.lang.Math can't be resolved (argument types: unknown).
Reflection warning, /Users/ikoszo/.m2/repository/org/clojure/clojure/1.11.0-alpha3/clojure-1.11.0-alpha3.jar!/clojure/java/math.clj:373:3 - call to static method max on java.lang.Math can't be resolved (argument types: unknown, unknown).
Reflection warning, /Users/ikoszo/.m2/repository/org/clojure/clojure/1.11.0-alpha3/clojure-1.11.0-alpha3.jar!/clojure/java/math.clj:384:3 - call to static method min on java.lang.Math can't be resolved (argument types: unknown, unknown).
Reflection warning, /Users/ikoszo/.m2/repository/org/clojure/clojure/1.11.0-alpha3/clojure-1.11.0-alpha3.jar!/clojure/java/math.clj:556:3 - call to static method scalb on java.lang.Math can't be resolved (argument types: double, unknown).
Loaded
Is this by design?We had this with Math/abs
previously and ended up using clojure.math.numeric-tower/abs
instead.
(in cases where we couldn't type-hint the call due to having to handle both long and double)
Woo I originally suggested convenience number parsing specifically for advent of code :smiling_face_with_3_hearts:
@U08BJGV6E no - how are you seeing that?
can't repro.
$ clj
Clojure 1.11.0-alpha3
user=> (set! *warn-on-reflection* true)
true
user=> (require 'clojure.java.math)
nil
Perhaps you're using java 17?I haven't tried but I'm assuming re-evaluating those fns one by one would result in the same
I don't see why
I also can't repro with Java 17 but I have seen one reflection issue before when upgrading when another same-arity/different-type overload got added.
Clojure 1.11.0-alpha3
user=> (set! *warn-on-reflection* true)
true
user=> (ns
^{:author "Alex Miller",
:doc "Clojure wrapper functions for java.lang.Math static methods.
Function calls are inlined for performance, and type hinted for primitive
long or double parameters where appropriate. In general, Math methods are
optimized for performance and have bounds for error tolerance. If
greater precision is needed, use java.lang.StrictMath directly instead.
For more complete information, see:
"}
clojure.java.math
(:refer-clojure :exclude [min max]))
nil
clojure.java.math=> (defn abs
{:doc "Returns the absolute value of a (long or double).
If not negative, a is returned, else negation of a is returned.
If a is Long/MIN_VALUE => Long/MIN_VALUE
If a is a double and zero => +0.0
If a is a double and ##Inf or ##-Inf => ##Inf
If a is a double and ##NaN => ##NaN
See: "
:inline-arities #{1}
:inline (fn [a] `(Math/abs ~a))
:added "1.11"}
[a]
(Math/abs a))
Reflection warning, /Users/ikoszo/Library/Application Support/JetBrains/IdeaIC2021.3/scratches/math.clj:362:3 - call to static method abs on java.lang.Math can't be resolved (argument types: unknown).
#'clojure.java.math/abs
clojure.java.math=>
on java 11I can see why this could happen - inside the abs
fn, there is no information about a
that could help the compiler choose the right method to call
Due to our previous adventure with abs I was really interested how this would be solved in the new ns, which is why I started poking around
It's the same thing some array based function in clojure.lang.RT, you can't really avoid reflection here unless you enumerate all possible input types and make special cases for them
Well, I don't have a solution, but it was surprising to see a reflection warning from a core ns. And according to Alex it wasn't intentional
This call is inlined, so it doesn't actually matter
While I'm not familiar with the concept of inlining in clojure, wouldn't it still result in reflection use when invoking (Math/abs a)
?
clojure.java.math=> (let [a 1] (abs a))
1
clojure.java.math=> (defn foo [a] (abs a))
Reflection warning, NO_SOURCE_PATH:1:15 - call to static method abs on java.lang.Math can't be resolved (argument types: unknown).
#'clojure.java.math/foo
I wonder if using https://github.com/clojure/math.numeric-tower/blob/master/src/main/clojure/clojure/math/numeric_tower.clj#L104 keeps being superior in those cases?
One could also wonder what (clojure.java.math/abs 1)
gives over (Math/abs 1)
, I mean, it's not like the interop was hard to type?
At least we get auto-complete for those functions in editors that have not so good Java support ;)
I'd consider it a good value add if clojure.java.math
could solve those reflection warnings 🙂
As has been discussed in #clojure-dev and the ticket, discoverability and avoiding interop were motivations
The numeric-tower impl relies on multimethods and boxing and other stuff that are not a good base for performance
Good points. Making these wrappers also helps beginners that are not so familiar with the JVM (discoverability)