Clojurians Log v2

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.

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

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

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.

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?

let me check...

oh, this came through the portal

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

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

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

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

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

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)

you are missing the reader part of the url

or I am missing the entire context

(A is all about the reader)

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

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

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 <http://clojure.org|clojure.org>, then that puts test.check in a pretty interesting position philosophically

that's the situation

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

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

@hiredman no, :/ can already serialize

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

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

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

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

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

or what they're intended to do, at least

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

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

edn is intentionally a subset of clojure's syntax

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

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

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

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

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

edn < clojure per spec < clojure per code

any of those are potentially interesting for generators

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

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

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

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

I've been using :/ in my code since early 2014 😄 https://github.com/gfredericks/lib-4395/blob/e4e23476b2df65684435baee5b52bf406de536ec/src/com/gfredericks/lib_4395.clj#L52

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

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

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

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

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

meaning you want stricter generators?

yes

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

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

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

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

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

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

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

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

it's easy to make your own primitives

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

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

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

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

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

does test.check have edn-makers?

or was that Stu's generative stuff that did that

or maybe it's in clojure's own tests

yeah, that's it - https://github.com/clojure/clojure/blob/master/test/clojure/test_clojure/generators.clj#L82

we use that a bit in some tests

that pool idea is interesting

I guess that's all against data.generators

Yeah

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

install_dir=PREFIX