This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-04
Channels
- # announcements (7)
- # beginners (37)
- # boot (6)
- # calva (13)
- # cider (13)
- # cljdoc (52)
- # cljs-dev (9)
- # clojure (117)
- # clojure-europe (3)
- # clojure-italy (12)
- # clojure-nl (21)
- # clojure-russia (8)
- # clojure-spec (77)
- # clojure-uk (20)
- # clojurescript (142)
- # community-development (6)
- # cursive (5)
- # datomic (13)
- # emacs (9)
- # figwheel-main (20)
- # fulcro (33)
- # graphql (11)
- # instaparse (6)
- # klipse (1)
- # off-topic (7)
- # om (8)
- # quil (7)
- # re-frame (11)
- # reagent (39)
- # reitit (10)
- # shadow-cljs (36)
- # spacemacs (3)
- # test-check (3)
- # tools-deps (83)
- # utah-clojurians (31)
- # vim (14)
There is some "core utils" with a index-by
function, that do (index-by :id [{:id 1}]) => {1 {:id 1}}
?? It's almost like group-by, but do not conj on value.
yes, there is, but often people write it themselves, using (into {} (map (juxt f identity) coll))
This PR for medley has been open for a while. I like the name index-by
better. Propose it đ https://github.com/weavejester/medley/pull/28
https://github.com/vodori/missing (a lib I maintain) has index-by and indexcat-by and groupcat-by :P
user=> (set/index [{:id 1} {:id 2} {:id 1 :x 2}] [:id])
{{:id 1} #{{:id 1, :x 2} {:id 1}}, {:id 2} #{{:id 2}}}
#graphql should be the one i think
I am using clojure.edn/read
to read an .edn file which contains #object[
tags like #object[java.io.File 0x6ae4aa5 "hello-world.pdf"]
Ideally I would like to interpret these as a record, something like (->EdnObject clazzname identityHashCode string-description)
at the moment I get an error
java.lang.RuntimeException: No reader function for tag object
Is the preexisting reader function that I can reuse to do this?
Do I have to write my own?I was hoping to wire in the binding using
(binding [clojure.core/*data-readers* (assoc clojure.core/*data-readers*
'object #'dev/my-special-edn-binding)]
does that only work for namespaced tags?oh I see I can just pass in :readers
in the options to clojure.edn/read
thus
(clojure.edn/read {:eof eof-sentinel :readers {'object #'dev/my-special-edn-binding}} r)
top banana
Why is spec imported as spec.alpha
? Does this notation imply that the interface is liable to change?
it has alpha in the name because it is alpha, yes
It just seems odd to explicitly notate it, since AFAIK breaking changes have happened in Clojure core even when not notated alpha
very rarely
trying to do better :)
(:require [clojure.spec.alpha :as s])
means that when it comes out of alpha you can just update that to (:require [clojure.spec :as s])
and (hopefully) not having to change your code đ
spec 2 dev is under way and will likely include some breaking changes
Except for those breaking changes đ
although we are trying to minimize those
We're very heavy users of spec and I have almost everything running at work on spec2 -- and the code changes weren't too extensive. I'm still working with Alex on a couple of issues tho'... đ
more changes to come, although I expect a lot will be additive
Sounds good - really I was just curious about the choice of notation, I'm not concerned too about having to make small changes to keep using spec đ
There was a good thread about the alpha
naming here https://clojureverse.org/t/are-clojure-core-alpha-namespaces-chosen-to-avoid-upgrade-conflicts/3722/5 -- relating to Rich's talk about semantic versioning and accretive design...
Thanks for the link @seancorfield
Strong adoption of Clojure 1.10 in the State of the (Clojure) Union survey results! Already 54% on 1.10. That's awesome. And only 3% on 1.7 or earlier. Great news for library developers.
I was actually disappointed it was so low :)
I am eager to move to it, but am being held back by CIDER not coping with the change in error format. Normally I adopt much faster. đ
Oops, it looks like they fixed that issue and I somehow missed it. I thought I was tracking the issue on GitHub. Itâs been a busy few months! I am trying again to move to 1.10.
in line with prior surveys - generally most people are on the last 2-3 releases
conversely, people who updated were much more likely to participate in the survey đ
always hard to predict the selection bias for respondents
agreed. really looking forward to the results. i like hearing from fellow clojure users
I'll throw in another data point: thanks a lot for the tireless great work you and your team put in @alexmiller!
agreed. immutable datastructures, a repl, and an alex. all features i value in Clojure
tell your friends :)
is this a pattern that people use?
#(do [:a :vector :or :other :literal])
or do most people opt for specific constructor functions (or into
etc) ?there are reasons why i don't always use a lambda but if a lambda is available to me, then I do opt for it first.
#(vector :a :vector)
^^ if you want a vector constructor, use the vector constructor
I think it is clearest way to say what you are doing here. you are invoking a function to make a vector from some elements
whereas #(do [âŠ]) is fewer characters but much weirder imo
another argument for do
is that it is possible to return any literal that way, not just the ones which happen to have a nice constructor (like say vector
or hash-map
).
donât all of the literals have a constructor though?
sorted-set, sorted-map, queue
ok, queue doesnât :)
@U0E98NQG2 #(âŠ) is a function literal
OK, sorry; I'm just basing this off of the Clojure docs: https://clojure.org/guides/higher_order_functions#_function_literals
the functionâs name is only known to itself, so itâs still anonymous to the outside
any reason for this preference? performance or aesthetic?
@borkdude yea, probably. was just staring at some code and wondered what other people thought.
I am seeing the weirdest thing: (symbol x) returning nil, when we are passing it a valid string without a slash, and both type
and class
report java.lang.String.
I'm going to see how far I can whittle down the example, but this is the current state: https://gist.github.com/eraserhd/f4f8f52fb43a2e4a5b6fc740a1101c02
So I'm trying to generate longs with clojure.spec.gen.alpha/large-generator
. This works fine when using generate
, but with clojure.spec.gen.alpha/sample
it generates extremely low values (+-60 from 0). I need it to generate pretty much the full range of longs. Any idea why it has this behavior?
it generates larger integers with a larger sample size
What I think it is trying to do is try the âedgeâ cases first, so zero, minus one, plus one, etc. Before actually switching to completely random longs
Hmm, seems your right. The numbers get more random as I get more. Anyway I can force it to be random from the beginning?
I am not sure, you can always define your own generator tho
May I ask, why donât you just increase the sample size?
Is there really no value in testing small values for you
Yeah, I'm testing dates. So one low value is fine (Jan 1, 1970), but then I want to start seeing other values. Having to scroll past the first 10 values in the web app is just wasting space, but it may be the easiest solution. Or I guess I could drop the first 10 or so values
Well - from a formal background - I understand why gen is doing this, bugs usually occur on boundaries. So testing for 0
, -1
, 1
etc. is usually more valuable than testing complete random values. Further reading: boundary analysis
thatâs not actually why - gen is designed to âgrowâ more âcomplexâ values as it generates more samples, then has support for âshrinkingâ a complex test case into a simpler one
https://github.com/clojure/test.check/blob/master/doc/growth-and-shrinking.md
you can use large-integer*
to generate longs with uniform distribution (note: specâs int-in
uses this so thatâs another path)
well, actually those might grow too
my memory was faulty
Hah, interesting!
I stand corrected ^^