Fork me on GitHub
#clojure-dev
<
2019-06-06
>
devn00:06:52

Speaking as someone who doesn’t own a project, I think it might be nice to create them with the caveat that project owners ultimately are in charge of changing them to fit their needs.

alexmiller01:06:51

Project owners should have that capability now afaik (but I haven’t tried it)

gfredericks01:06:33

I was able to change the auto-assignee, at least I did that because I realized I wasn't getting emails for new tickets like I used to getting assigned will probably mean I get an email

alexmiller16:06:05

FYI, Contegix is experiencing a wide network outage. Contegix hosts the box for the Clojure build server (http://build.clojure.org) and that is currently unavailable.

polymeris18:06:11

I'd like to reply to https://clojure.atlassian.net/projects/TCHECK/issues/TCHECK-155 -- it seems an account was created for me, but I don't have access to any projects?

alexmiller18:06:29

let me check...

alexmiller18:06:18

oh, this came through the portal

gfredericks18:06:40

speaking of which, can anybody authoritatively comment on TCHECK-155?

gfredericks18:06:14

(that was not a question about jira commenting capabilities, it was a request for clojure design info)

hiredman18:06:36

it looks like the same old thing, the assumption that the universe of things that are valid for serialization(pr,read,edn) is the same as the universe of things

gfredericks18:06:11

well in particular I'm thinking that exactly one of the following must be true A) the clojure reader accepting :/ is a bug and it should be fixed B) test.check should generate :/, because it's de facto valid and so useful for testing

gfredericks18:06:49

but I can't tell which of those is true without an Official Ruling

polymeris19:06:11

My reading of https://clojure.org/reference/reader#_reader_forms is that: • keywords are symbols that start with :. • / is only valid in a symbol either by itself or separating ns from name (neither of which :/ satisfies)

hiredman19:06:05

you are missing the reader part of the url

hiredman19:06:28

or I am missing the entire context

hiredman19:06:45

(A is all about the reader)

gfredericks19:06:04

> it looks like the same old thing, the assumption that the universe of things that are valid for serialization(pr,read,edn) is the same as the universe of things this doesn't sound right, because in this case :/ is fully readable and printable; the only thing it's at odds with is the documentation (and apparently something very subtle in cljs)

hiredman19:06:04

but the ticket seems to take the approach of removing :/ from the generated keywords

gfredericks19:06:05

if we're committed to a situation where certain kinds of code subtly break and the only way to know that you shouldn't have written that code is to read things on , then that puts test.check in a pretty interesting position philosophically

alexmiller19:06:51

that's the situation

hiredman19:06:15

so the question is is the keyword generator only supposed to generate keywords that serialize, or can it generate any possible keyword object that can exist

alexmiller19:06:17

http://clojure.org is state what is supported, the code allows more than that but does not commit to it always working

gfredericks19:06:29

@hiredman no, :/ can already serialize

alexmiller19:06:00

:/ is kind of a weird case because / was kind of wedged into symbol support and namespaced symbol support later on

hiredman19:06:04

sure, but the comment on the ticket, and it looks like the patch on the ticket removes it from the generator because it doesn't match the edn spec

hiredman19:06:37

where the edn spec is a spec about serialization, not a spec about objects that can exist in a runtime

hiredman19:06:59

(regardless of how faithful any of the readers are to that spec)

gfredericks19:06:09

I don't think test.check should care about what the edn spec says if it differs from what clojure.core/{read,pr} do

gfredericks19:06:18

or what they're intended to do, at least

hiredman19:06:45

why should it care about what read/pr do even?

gfredericks19:06:59

I think that's more compelling than saying it should care about edn; edn's only interesting inasmuch as it's evidence for what's officially supported in clojure, but docs/comments about the clojure language itself are what we actually care about

alexmiller19:06:18

edn is intentionally a subset of clojure's syntax

gfredericks19:06:22

you could also say it should just generate any object that can be created in any fashion, I'm not distinguishing those two at the moment

gfredericks19:06:01

@alexmiller and that particular relationship (subset) doesn't resolve the :/ question -- :/ could be invalid edn, but still valid clojure

alexmiller19:06:44

right, my point being that edn is interesting because it's a format for external data files and is more restrictive than clojure

alexmiller19:06:59

such that it may be important to test with the more restrictive set

gfredericks19:06:04

yeah, I imagine knowing it's a subset means that if something is valid edn, it must be valid clojure as well

alexmiller19:06:29

edn < clojure per spec < clojure per code

alexmiller19:06:58

any of those are potentially interesting for generators

gfredericks19:06:34

yeah a cute thing test.check could do is test if (read-string ":/") succeeds, and avoid generating it if not that'd make it do The Right Thing in some future world where the reader gets stricter

alexmiller19:06:51

first question for this ticket is, can we resolve which set :/ is in

gfredericks19:06:11

based on what you've said already I'd assume it's only clojure-per-code

alexmiller19:06:28

well, I might be able to resolve this better with the man upstairs

gfredericks19:06:34

I'd be much more comfortable with this situation if :/ wasn't broken in cljs

gfredericks19:06:36

I think that's the worst part; I'd argue either the cljs compiler & runtime should be modified to prevent creating :/, or the hash-code or whatever the underlying problem is should be fixed

gfredericks19:06:03

I suppose test.check can detect that bug at load-time as well, and suppress generation of :/

gfredericks19:06:36

but in general it's not obvious what a data generation library should do in this situation, short of providing multiple categories of generators 😕

alexmiller19:06:35

I frequently want generators from test.check that are similar to the existing ones in this kind of way

gfredericks19:06:50

meaning you want stricter generators?

alexmiller19:06:58

I have no particular example in my head at the moment but have frequently found myself staring at the docs for generator namespace wishing I had something like what's there but slightly different

gfredericks19:06:59

I thought a decent amount about expanding the generator API to make it easier to customize them

alexmiller19:06:28

the next time I'm in this bucket I'll drop you a note somewhere with an example

gfredericks19:06:56

the cljs :/ bug seems to make them similar to NaNs

alexmiller19:06:04

that seems bad and fixable, even in the gray area of maybe-allowed

gfredericks19:06:21

the idea was basically to add a third arg (in addition to rand and size), presumably called opts, which is just a map that gets passed down to leaves the same way size does, and can be customized in a similar sort of way

gfredericks19:06:01

off the top of my head I can't remember any downsides

alexmiller19:06:02

I'd really like more flexible primitives so I can compose myself to glory, rather than options

gfredericks19:06:52

it's easy to make your own primitives

gfredericks19:06:07

the options would especially target situations where somebody else (e.g., spec) is assembling the generator for you

gfredericks19:06:19

e.g., (def keyword-but-not-slash (gen/such-that (complement #{:/}) gen/keyword))

gfredericks19:06:46

the hard part is tweaking a complex generator to never generate :/ anywhere

gfredericks19:06:25

if there were an obvious right answer to this I would have done it already :face_with_rolling_eyes:

gfredericks19:06:02

e.g., gen/any is not very useful if it has to dictate all these choices, and you'd get a combinatorial explosion of gen/anys if you wanted to provide all possibilities

alexmiller19:06:22

does test.check have edn-makers?

alexmiller19:06:36

or was that Stu's generative stuff that did that

alexmiller19:06:06

or maybe it's in clojure's own tests

alexmiller19:06:18

we use that a bit in some tests

gfredericks19:06:55

that pool idea is interesting

gfredericks19:06:24

I guess that's all against data.generators

mfikes23:06:49

With the latest homebrew release, I'm getting an odd thing where, in /usr/local/bin/clojure, it ends up with

install_dir=PREFIX
Not sure what the root cause might be yet; just sharing.