This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-16
Channels
- # beginners (21)
- # boot (6)
- # cider (47)
- # clojure (67)
- # clojure-brasil (2)
- # clojure-dusseldorf (3)
- # clojure-greece (2)
- # clojure-quebec (3)
- # clojure-russia (8)
- # clojure-spec (110)
- # clojurescript (19)
- # cursive (8)
- # datomic (5)
- # devcards (2)
- # dirac (9)
- # editors (1)
- # emacs (3)
- # funcool (1)
- # lein-figwheel (7)
- # om (1)
- # protorepl (2)
- # re-frame (1)
- # testing (1)
stuarthalloway: resizing with some multiple of square root would give another size growth pattern
I think Stu left this on my plate so I will take a look next week, thx
If we conform a map to a spec using the unnamespaced keys, is there any way to get the map returned using the fully-qualified specs keywords as keys? I threw together a hacky and incomplete version of this, hoping there's an easier way.
@dave.dixon spec doesn't provide an explicit tool for that
It is possible if you did an s/merge of s/keys and s/map-of with :conform-keys true and a conformer key pred
Hey; is there any particular library for common specs like URI/URLs, dates, &c that’s forming/informally?
It might be useful to do so generally because a lot of this stuff appears to be string matching a regex
so you're saying it's time for me to create clojure.schpec
I’ve done some initial work towards such a lib, but it’s more aspirational and experimental than not atm: https://github.com/SparkFund/useful-specs/tree/master/src/specs
one of the problems I saw with Schema was that there were a bunch of subtly overlapping ones
Also, if it’s clojure.schpec that’d be like chuck, outside the stdlib, so nobody has to rewrite instaparse?
Yeah, I hope that between clojure core and 1 or 2 community libs, we’ll have a solid shared design vocabulary
Loading the tld resource?
Just that I have to require the ns somewhere before I can go use :whatever/whatever, because of the side-effecty def, right?
Oh, yeah, the keyword focus has some interesting consequences
lvh: yes to both of those
the idea would be "a big pile of half-baked utilities related to clojure.spec"
could also name it spock I suppose :/
I'm not big on star trek themes in general but I don't know what sort of mascot is suggested by the name "schpec"
clojure.spook
spectacles
They help you see things more clearly
that's way too positive
I think ghost-themed is promising
maybe spelled spooc
I did like "spectacles" when I was accidentally reading it with emphasis on the middle syllable though
dammit that happened with spuck too
according to alexmiller at least; I'm not sure if he was thinking of the urban dictionary entry, which has the usual difficult-to-assess relevance level
I’ve heard first
, mostly outside of the US (Jewish parts of Antwerp, so may be reasonably common Yiddish though), the rest
look made up,
spook is very definitely relevant according to some of my non-former-intelligence coworkers from the deep south
spooky or spookily don’t carry the spy connotation
donaldball: Not worried about the spy connotation, worried about the racist epithet for people of color 🙂
donaldball: it was weird to the deep south coworkers because they weren’t used to the former but definitely heard the latter growing up
Wow. I grew up in Tidewater and thought I’d heard ‘em all, but that’s a new one to me.
Wow. I heard it used that way as a kid (visiting family in Mississippi, probably) but had completely forgotten that usage. That's … progress, I guess?
Cache invalidation and naming things, right?
sperc
there's always spork
… which has been used as the name of a testing library before, so no chance for confusion! :face_with_rolling_eyes:
there are no names left
I've half a mind to call it lots-of-code-related-to-clojure.spec
don't like including the letter 'c'?
alexmiller: I just made this commit (on a branch): https://github.com/clojure/test.check/commit/f7d9230a3afae303fdb466230a780aa71901a853
That's the only potential improvement to test.check that I've heard discussed that would have to be released before 1.9 is released
gfredericks: So, JSON Schema… I was thinking of just having something that generates specs for me; except of course it’s hard to check that something was (keys :req-un [...])
or whatever because they don’t compare identically; so I guess now I’m building a schema, using test.check to generate samples, and then using a JSON schema validator that consumes to validate that the things that were generated validate the original schema
your problem is you can't compare clojure.spec specs for equality?
can you use the data representation of the schema to do that in a good enough way?
I mean clojure.spec lets you get the form of a spec
somehow
I might be misunderstanding
I was going to say that the main problem I have then is that the registry is global state, and I’m generating them for tests
yeah that's what I was thinking of
generate uuid namespaces to register your specs under :)
probably with any direct pred
(s/def ::string string?)
and (s/form ::string)
would work I bet
@alexmiller: Thanks, slick solution much better than my hand-mangling of the spec. Almost worked, s/merge
caused the unnamespaced keys to also make it through. Using s/and
did the trick.
@lvh if it's a problem that the registry is global state, do you have to use it? Can you just generate the specs and handle them as you need in local state, rather than using s/def
?
Hmm … you're right about keys, but every-kv just takes two predicates. (And you'd probably want to use map-of instead of every-kv, unless you don't want full validation.)
That is an interesting problem, though … I can see how keys
would be useful for spec'ing data structures in contexts where you wouldn't want to use the global registry.
Are there going to be specs for spec?