Fork me on GitHub
#clojure-spec
<
2016-07-16
>
gfredericks00:07:40

stuarthalloway: resizing with some multiple of square root would give another size growth pattern

Alex Miller (Clojure team)01:07:53

I think Stu left this on my plate so I will take a look next week, thx

sparkofreason04:07:56

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.

Alex Miller (Clojure team)12:07:37

@dave.dixon spec doesn't provide an explicit tool for that

Alex Miller (Clojure team)12:07:43

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

lvh14:07:57

Hey; is there any particular library for common specs like URI/URLs, dates, &c that’s forming/informally?

lvh14:07:08

It might be useful to do so generally because a lot of this stuff appears to be string matching a regex

lvh14:07:30

meaning that if it’s third-party, test.chuck can automatically give you generators

gfredericks15:07:01

so you're saying it's time for me to create clojure.schpec

lvh15:07:40

I’m writing a library that I think I will call ehm, specimen or something

lvh15:07:43

it’s json-schema => spec

lvh15:07:08

because I was translating swagger => spec and that was really boring repetitive work

lvh15:07:45

but I figured I could get a computer to do it for me

lvh15:07:52

the json-schema spec is also itself available as a json-schema

lvh15:07:55

I’m not sure what that means yet

donaldball15:07:20

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

lvh15:07:33

one of the problems I saw with Schema was that there were a bunch of subtly overlapping ones

lvh15:07:37

not necessarily well-maintained

lvh15:07:30

gfredericks: Is json-schema => spec something you’d consider for clojure.schpec?

lvh15:07:46

Also, if it’s clojure.schpec that’d be like chuck, outside the stdlib, so nobody has to rewrite instaparse?

donaldball15:07:08

Yeah, I hope that between clojure core and 1 or 2 community libs, we’ll have a solid shared design vocabulary

lvh15:07:11

(heck maybe instaparse should just go into clojure, maybe not though)

lvh15:07:34

donaldball: side-effecty namespace loading womp womp 😞

donaldball15:07:59

Loading the tld resource?

lvh15:07:31

donaldball: Not specific to your thing

lvh15:07:47

Just that I have to require the ns somewhere before I can go use :whatever/whatever, because of the side-effecty def, right?

lvh15:07:56

kinda the same problem as having multimethod impls

lvh15:07:11

donaldball: It’s not a criticism of your project; it is a generic problem

donaldball15:07:27

Oh, yeah, the keyword focus has some interesting consequences

gfredericks15:07:40

lvh: yes to both of those

gfredericks15:07:56

the idea would be "a big pile of half-baked utilities related to clojure.spec"

lvh15:07:12

I want to pronounce schpec as speck, so now I am hungry

gfredericks15:07:25

could also name it spock I suppose :/

gfredericks15:07:54

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"

gfredericks15:07:52

clojure.spook

donaldball15:07:42

They help you see things more clearly

gfredericks15:07:03

that's way too positive

gfredericks15:07:42

I think ghost-themed is promising

gfredericks15:07:11

maybe spelled spooc

lvh15:07:32

spook has unfortunate connotations though

gfredericks15:07:34

I did like "spectacles" when I was accidentally reading it with emphasis on the middle syllable though

lvh15:07:05

you could totally pull off Speck for shpec

gfredericks15:07:30

dammit that happened with spuck too

lvh15:07:52

unfortunate connotations?

lvh15:07:43

I don’t recongize that one, but yeah that sucks

lvh15:07:53

it’s weird because I work with a ton of former intelligence people

lvh15:07:05

so spook is a generally accepted word for them internally

gfredericks15:07:26

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

lvh15:07:53

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,

lvh15:07:28

spook is very definitely relevant according to some of my non-former-intelligence coworkers from the deep south

donaldball15:07:36

spooky or spookily don’t carry the spy connotation

lvh15:07:16

donaldball: Not worried about the spy connotation, worried about the racist epithet for people of color 🙂

lvh15:07:42

donaldball: it was weird to the deep south coworkers because they weren’t used to the former but definitely heard the latter growing up

lvh15:07:48

I think spooky doesn’t have that one either though

donaldball16:07:46

Wow. I grew up in Tidewater and thought I’d heard ‘em all, but that’s a new one to me.

glv16:07:57

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?

donaldball16:07:03

Cache invalidation and naming things, right?

lvh16:07:32

gfredericks: sperc sounds derpy, for sure

gfredericks16:07:08

there's always spork

glv16:07:00

… which has been used as the name of a testing library before, so no chance for confusion! :face_with_rolling_eyes:

gfredericks16:07:35

there are no names left

gfredericks16:07:33

I've half a mind to call it lots-of-code-related-to-clojure.spec

lvh16:07:40

shpec is great though!

lvh16:07:54

sounding like meat products doesn’t sound bad

gfredericks16:07:17

don't like including the letter 'c'?

lvh16:07:51

sorry, my misspelling; no opinion 🙂

gfredericks18:07:47

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

lvh18:07:03

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

gfredericks18:07:46

your problem is you can't compare clojure.spec specs for equality?

lvh18:07:19

I have a json schema and I want a fn that returns the equivalent specs

lvh18:07:35

as a map, probably, because having a fn eval a bunch of spec/def exprs seems bad

gfredericks18:07:39

can you use the data representation of the schema to do that in a good enough way?

lvh18:07:11

I don’t know, that’s the hypothesis, yes

lvh18:07:28

are you asking if the very idea of going from json schema -> spec is possible?

lvh18:07:44

I also want it as data because I presume that you will want to modify/extend it

gfredericks18:07:09

I mean clojure.spec lets you get the form of a spec

gfredericks18:07:27

I might be misunderstanding

lvh18:07:08

I’ll take a look at the api docs then

lvh18:07:25

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

lvh18:07:39

I’m hoping I can with-redefs it or something

lvh18:07:09

(spec/form spec) apparently!

gfredericks18:07:21

yeah that's what I was thinking of

gfredericks18:07:35

generate uuid namespaces to register your specs under :)

lvh18:07:46

(clojure.spec/keys :req [:xyzzy.spec.json-schema/a])

lvh18:07:59

is what I got out

lvh18:07:03

awesome, thanks 🙂

lvh18:07:30

I’m still writing the generative tests though

lvh18:07:53

(s/form string?) ;;=> :clojure.spec/unknown 😞

lvh18:07:58

same with inst?

gfredericks18:07:54

probably with any direct pred

gfredericks18:07:12

(s/def ::string string?) and (s/form ::string) would work I bet

sparkofreason19:07:31

@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.

glv20:07:16

@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?

lvh21:07:02

glv: I’m speccing maps, so wouldn’t I need to use keys or every-kv?

lvh21:07:06

keys takes a spec name

glv22:07:26

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.)

glv22:07:50

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.

sparkofreason23:07:37

Are there going to be specs for spec?