[org.clojure/spec.alpha "0.1.134"]

Renamed the issue. Instead of Keyword argument, it should take a function to walk the spec to support arbitrary walking applications.

I ran into this while trying to wrap calls to a queue: https://stackoverflow.com/questions/49862954/clojure-proxy-multithreading-issue

org.clojure/spec.alpha "0.1.143"

Clojure 1.9.0
org.clojure/spec.alpha 0.1.143
org.clojure/test.check 0.9.0

Can you squash the patch?

Sure done.

Thanks!

any

I've attached a patch which fixes this problem by bringing Clojure's try/catch semantics more inline with Java. For each catch clause, the compiler checks if a previous catch clause is a supertype if the current one. If it is, an IllegalArgumentException is thrown. This is O(n^2) in the number of catch clauses, but since n will be low in the vast majority of cases, and since the work is done at parse time, it should not pose any performance issues.

I had to modify an unrelated test since it actually had multiple catch clauses that caught Exception which is no longer allowed with this patch.

The compiler should never produce byte code that has VerifyErrors so this is definitely a bug.

This issue also exists in ClojureScript (which is where we first discovered it).

The rejected fix for CLJ-1242 that protected entryAt from ClassCastException would have fixed this as well. The root of the issue is that the exception can come from checking keys so it makes sense to fix it there. The accepted fix for CLJ-1242 protected only the = test with the sorted-map first. The more basic key access question was punted. I expect this to work:

(= (get (sorted-map 1 2) :a :missing) :missing)

I think it's worth taking another look at entryAt. Most users would expect the following to succeed:

(every? (fn [create] (= (get (create 1 2) :a :missing) :missing)) [hash-map array-map sorted-map])

If there's a performance concern, then the restriction on testing keys should be documented.

Clojure 1.9.0. MacOS 10.12.5

Another similar situation: try pretty printing (ns) - you get a stack overflow.

This behavior is consistent with ClojureJVM.
That doesn't mean it is correct.
However, I prefer errors that originate with ClojureJVM be fixed there first and then migrate over to ClojureCLR as I update to their patches.
I am inquiring about transferring this over. If there is no direct way to transfer, I will post a JIRA issue on this with them.

Some use cases for this are also when you have partially applied all the arguments to a function already and want to call it.

(map (comp :result invoke) fns)

apply can't be used for these cases as it requires arguments to be provided.

apply is clear about requiring a final args list argument.

(apply println []) is the correct usage and I don't think it makes sense to make this a special case.

To me, the last sentence indicates that "split" (as a noun) is being used to refer to the parts resulting from splitting but there is some ambiguity in the prior sentence. Would "parts" be better?

I don't get your point on the clojuredocs examples - those make sense to me.

The docs are a bit ambiguous as "splits" is a verb in the first sentence, but a noun in the other two occurrences. I believe the ClojureDocs example being referred to is likely this one (mostly because of the comment in it):

; Note that the 'limit' arg is the maximum number of strings to
; return (not the number of splits)
user=> (str/split "q1w2e3r4t5y6u7i8o9p0" #"\d+" 5)
["q" "w" "e" "r" "t5y6u7i8o9p0"]

Because split is the name of the function and the action being performed, I think it makes sense to leave it as the verb in the first sentence and replace the other two occurrences with "parts". Does that sound reasonable?

Incorporated these changes into the existing pending patch for the same function at CLJ-1360.

Probably documenting would be safer than changing the behavior at this point, given that some people may actually rely on the current behavior after testing, deploying, etc.

I don't currently have a suggestion for a modified doc string, but note that there are examples of this behavior and how one can use an extra "-1" limit argument at the end to get all split strings: http://clojuredocs.org/clojure_core/clojure.string/split

This bug just bit me. +1 to be fixed. If we just document and leave the behavior as is, then we have a surprising and inconsistent behaving split (why are inner empty values kept, but outer ones stripped?) that is different to every other split you've ever used. The optional -1 limit argument looks hacky but a fix could keep this -1 argument working.

EDIT: this looks to be java's string class behavior: http://stackoverflow.com/questions/2170557/split-method-of-string-class-does-not-include-trailing-empty-strings
Would be nice if limit defaulted to -1 on that type of clojure.string/split call.

This is really gross, and the original developer has been punched in the neck. (Ow.)

I hate the Java leakage, but given that this is already out there, and that people are likely already relying on both the default and the negative-arg behavior, I think the least bad bet is to document precisely the semantics we have.

Incorporate changes from CLJ-1857 in clj-1360-2.patch.

org.clojure/spec.alpha "0.1.143"

You can't instrument a macro, so that part of the ticket doesn't make sense as written. But I expect you mean the spec check during macro expansion.

In the macro check case, the caller info is known by the compiler and included in the wrapper CompilerException. I suppose that info could be passed into s/macroexpand-check from the Compiler and possibly produce similar results as with instrumented function calls.

Ah, you're correct, thanks for clarifying.

If caller information was added, it would also be very useful to add a specific `:clojure.spec.alpha/failure` value for specs that fail during macro expansion. That would allow 3rd party tools to show specific types of error messages when macro expansion failed.

Additionally, having access to the symbol for the macro name would assist in error reporting.

IMHO explain-data for instrumentation failures and macro spec errors should contain the fspec of the function (or macro), as I suggested before in CLJ-2218.

An fspec has some useful info (such as the ns-qualified name symbol and the line number etc.) of the spec'ed function in its metadata, so spec error reporters can use them for richer and more precise error messages in a uniform way for both instrumentation failures and macro spec errors.

Mac OS X 10.10.2, JDK 1.8.0_31

Patch attached. It's about 25% faster on a simple test like:

(time (transduce (take-nth 13) + (range 1e7)))

I didn't worry about (take-nth 0) case, but my patch does give a different result. The current implementation gets a divide by zero error (from rem). My patched version returns just the first element once. The regular collection version returns an infinite sequence of the first element. I doubt anyone expects a sensible answer from the 0 case so I didn't try to do anything special with it.

Nice =)

I would say that the transducer version really ought to match the collection version as closely as possible, but I don't think there's actually a way to write a transducer that transforms a finite sequence into an infinite sequence, so no luck there.

Maybe while we're at it we should change both the transducer and the collection arities to throw on zero?

GIGO case, but rem is also responsible for:

user=> (take-nth 2.5 (range 10))
(0 3 6 9)
user=> (sequence (take-nth 2.5) (range 10))
(0 5)

The patch by Steve (CLJ-1665-faster-take-nth-transducer-without-rem.patch) is just missing a cast to int to solve the above:

(defn take-nth [n]
  (fn [rf]
    (let [n (int n)
          iv (volatile! 1)]
      (fn
        ([] (rf))
        ([result] (rf result))
        ([result input]
         (let [i (vswap! iv dec)]
           (if (zero? i)
             (do (vreset! iv n)
                 (rf result input))
             result)))))))

Perhaps the existence of other kinds of map entries would matter to users of such a constructor.

user=> (let [me (first (sorted-map :a 1))]
         [(map-entry? me) (type me)])
[true clojure.lang.PersistentTreeMap$BlackVal]

I don't see the point. What would having a map entry constructor achieve?

Mike: no, I don't think that should matter

Ghadi: there is code out in the wild that invokes MapEntry/create because it's faster in some cases - this would certainly be preferable.

Ghadi: another consideration is clj\cljs portability. Speaking of which...

Alex: should I create a ticket for clojurescript too? Seems like the body of the function would be:

(cljs.core/MapEntry. k v nil)

This is the first time I've submitted a patch, please let me know if I did something incorrectly. Also, I haven't signed the CLA yet, but I will be able to do so in the next few weeks.

It’s the same with plain reduce:

(reduce ((partition-all 3) conj) [] (range 10))
; => [[0 1 2] [3 4 5] [6 7 8]]

I believe completion is a feature of transduce, not necessarily of other transducible processes.

Operating system details :

$ uname -a
Linux ubuntu-s-1vcpu-1gb-blr1-01 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Java version :

$ java -version
java version "10" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10+46)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)

I just tried `mvn package` with Clojure 1.9 release commit and could see the same test case failing. Attached a log of the same with the ticket.

Commit hash : 841fa60b41bc74367fb16ec65d025ea5bde7a617

dupe of CLJ-2330

This can be closed. I tried "JDK 10" in JIRA search and reported this since I couldn't find any related issues. Sorry for the noise.

JDK 9 or higher

Static or default interface method invocations are not supported when the bytecode emitted is < 1.8 bytecode (Clojure currently emits 1.6 bytecode). I'm mildly surprised this compiled.

Not sure Ghadi’s assertion is correct? No new bytecodes were introduced for static and default interface methods. Or at least I have been using JDK 8 utilities like CharSequence.codePoints() and Comparator.reverseOrder() in Clojure for a long time. (And if this usage were not supported today that would seem like a critical issue.)

Yeah, I'd expect default interface methods to just be filled in on classes which don't provide their own implementation, and empirically they don't seem to cause any issues, but I'm not an authority on JVM bytecode.

while it is true that no bytecodes were introduced, the JVM spec mandates that invocations to static interface methods refer to an InterfaceMethodref entry in the constant pool rather than simply to a Methodref – as to why this worked in jvm 1.8 and fails with a verify error in jvm 9 , I can only assume the bytecode verifier became stricter since version 9

See https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-5.html#jvms-5.4.3.3, describing the resolution rules for Methodrefs:

When resolving a method reference:

    If C is an interface, method resolution throws an IncompatibleClassChangeError.

Indeed here's the openjdk ticket tightening bytecode verification to adhere to the JVM spec: https://bugs.openjdk.java.net/browse/JDK-8145148
According to the last comment on that ticket, upgrading the ASM version provided with clojure to 5.1 should fix this

The following 3 patches work to fix this problem, I've kept them split for now so that we can be evaluated separately, but in order to fix this all three are required.

1st patch simply updates the version of ASM that clojure uses to 6.0, removes the bundled ASM and adds ASM as a separate dependency. If this is not desirable we could just update the bundled version of ASM but it seems like now that clojure requires external deps, this is up for debate.

2nd patch updates the classfile version that clojure emits from 1_5 to 9 so that ASM can emit interface method refs, because of changes in bytecode verification since v1.5, several additional changes were needed:
1- it's not possible anymore to assign final fields from methods other than <clinit>, so it was necessary to mark the const__ fields as non final as they are assigned by init__n methods
2- stack map frames are not optional anymore so we need to tell ASM to compute them for us
3- a custom ClassWriter overriding getCommonSuperClass has been implemented, using DCL to load classes and short circuiting on classes that are being defined (as per that method's javadoc)

finally the third patch addresses this issue by emitting `invokeStatic` through the new `visitmethodInsn` arity that supports interface methods

Note that I'm not proposing the 3 patches as they are as a fix for this, given that bumping classfile version means discontinuing support for running clojure on java versions earlier than what's specified, which is undesiderable (I've bumped it to V9 but what's needed here should be just V1_8, but still).

That said, if we want to fix this, we definitely need the fixes I've put in those patches and we likely also want to conditionally emit different classfile versions (e.g. defaulting to 1_5 but bumping it to a higher version for specific classfiles when needed)

Nicola Mometto are sure you sure upgrade the V1_8 is needed to address interface static and/or default methods? CONSTANT_InterfaceMethodref is not new it was in the instruction set since forever (and in V1_6 particularly https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html#42041).

Vladimir Tsanev InterfaceMethodref is not new, but supporting `invokeStatic` on an InterfaceMethodref is only supported since V1_8

Attached v2- patches. Please read patch-3 commit message carefully.

I consider this a very high priority defect when running Clojure on Java 9. Some libraries (notably the new AWS SDK) are beginning to make use of static methods on interfaces.

The v2- patches enable JDK8 bytecode, which allows Clojure's bytecode to correctly call these methods without throwing an exception. This sheds compatibility for JDK 7. Android should no longer have problems with JDK8 bytecode.

ASM is now hosted on git, and the first patch's commit message contains a useful vendoring script.

As a side-effect loading Clojure is consistently about 5% faster across a few machines I tested (x86 & ARM). I did not test compilation speed.

asm 6.1 is released which does not have any new features (except java 10 bytecode version). It should be binary compatible, but have few runtime changes - probably worth checking if everything is ok against the new version. They also changed the code style - another good reason to unbundle asm since merging will become harder.

The patch in v2-0001 is already based on the ASM-6.1 branch but not the final release. Can bump it with the script in the commit comment.

Workaround macro:

(defmacro interface-static-call
  [sym & argtypes]
  `(let [m# (.getMethod ~(symbol (namespace sym))
                        ~(name sym)
                        (into-array Class ~argtypes))]
     (fn [& args#]
       (.invoke m# nil (to-array args#)))))

(def client
  (interface-static-call S3Client/create))

Ubuntu Linux 14.10
Clojure 1.6.0
OpenJDK 64-Bit Server VM 1.7.0_65-b32

`comment` is a macro, it doesn't bypess the reader.
":" is not a regular clojure token so it's expected that this throws.
The only way to include non clojure tokens in a source code is after a ";" comment

I've just added some notes about this to ClojureDocs.org here: http://clojuredocs.org/clojure.core/comment

agreed with Nicola's comment above

macOs 10.12.6

not on analysis, on compilation.

deftype has a compilation time effect. similarly def has a compilation time effect.

so

(when false (def a 1))

will result in the var for a being interned, but it won't have a root value.

the reason wrapping in (comment ...) stops whatever from happening is compilation happens after macroexpansions, and the comment macro replaces whatever form with nil.

I am not sure this would be considered a bug. The only way to avoid this would be to have deftype generate types at runtime instead of at compile time, but I am pretty sure the types are generated at compile time to 1. avoid generating a new type every time the compiled expression is run 2. to make class generation fairly predictable so clojure can be used in environments with unusual classloader restrictions.

maybe take a look at compile-if https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/reducers.clj#L24-L35

As Kevin commented, this is the intended behavior.

Noted. compile-if is what we need. Apologies for the noise.

This patch seems somewhat removed from the cause - is there some way to instead prevent the lib from being added to loaded-libs in the first place?

To do so, I think we need to revert CLJ-1116.

I don't think this solution is good as is so moving to Incomplete.

What kind of solution are you expecting for this problem?

To prevent the lib from being added to loaded-libs in the first place, I think ns macro needs to know where it is used from. It should immediately add the ns when used in the REPL for CLJ-1116, while it should defer adding the ns until completing loading whole the file without errors when used within a file.

Attached a similar approach as Shogo Ohta's original. Given the way ns now works, I see this approach as tenable.

To support dynamic ns creation at the REPL, CLJ-1116 wrote to loaded-libs inside the ns macro, and at the same time made some logic in load-lib and load-libs unnecessary. This set of patches undoes the side-effect when loading fails, and cleans up some dead conditionals.

New behavior: Given ns A which requires #{B, C}, if B loads but C doesn't, only B will be written to loaded-libs, and A and C will be undone. This improves the experience with load and fixes all of the annoying behavior in the ticket description.

NB: the 'require' patch entails:
If a lib is specified in an ns :require or :use, loading that lib the first time must result in an ns that corresponds exactly to the lib name. (There is not and has never been this restriction when calling `load` directly, but only via `ns`) I was surprised to find in the test suite an accidental lib with underscores where the loaded code results in a namespace with a dash. (Perhaps c.c.specs should specify a tighter spec for libs than 'simple-symbol?')

The commits are separated, with accompanying short explanatory comments.

tested on CentOS 6

The Scala community found this issue a while ago, and now the compiler has a max-classfile-name parameter (defaulting to 255). Hashing is used when the limit is exceeded. Maybe we should consider something similar?

I tried clojure.core.match with 13 patterns and the compiliation failed under Windows. I assume this problem is the root cause of it.

Some more info on that:

A colleague of mine just ran into that problem because he's using Linux / eCryptfs (where the limit of 143 is rather small, compared to our FileVault encrypted macOS used otherwise): see https://bugs.launchpad.net/ecryptfs/+bug/344878.

However, Clojure's not alone with that problem, Scala is also hit hard: https://issues.scala-lang.org/browse/SI-3623

There's no "easy" solution to this, and truncating the filename (as Scala does) bears a lot of other problems, obviously.

For all of you bitten by this problem, one possible workaround might be the one proposed by Mario Pastorelli (https://issues.scala-lang.org/secure/ViewProfile.jspa?name=melrief) in comment https://issues.scala-lang.org/browse/SI-3623?focusedCommentId=76104&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-76104:

Use an unencrypted filesystem to temporarily store classfiles, maybe by having a tempFS to keep stuff in memory. Not the best way, because we do not like leaving important stuff unencrypted, ...

Hello,

I run into the same problem while using clojure.core.match. I macroexpand the function definition and observe that the macro-expanded definition is deeply nested.

I think one way to solve it is to provide an option to wrap the class file as a jar with some shorter file name so that the the class name can remain the same (zipped file name can be as long as you like, right?). WDYT?

Btw, I am using clojure 1.9.0 so I think we should say that this bug affects 1.9 as well.

I come up with a proof-of-concept patch. The compiler now outputs jar instead of class if the class name is longer than 255. The jar name is simply a (left) truncation of the class name.

Suppose *compile-path* is set to "build", then you need to add build/* to your class path, so that the jars can be found.

This patch is only a proof of concept, ideally all classes with long name should be put into one big jar to avoid having to decompress many files. Also, the user should be able to specify *compile-name-max* and *compile-jar-name*. Finally, the code is quite ugly, I should have spitted things into several functions.

Alex - we're not going to output jars. This is at odds with many facets of the Clojure runtime.

Sorry if this comment is off topic, but the original example is a bit confusing to me. Maybe it should be:

(defmacro nestfn [n & body]
  (if (> n 0)
    `(fn [] (nestfn ~(dec n) ~@body))
    `(do ~@body)))

That way (trampoline (nestfn 10 "foo")) would return "foo". However, I do get a CompilerException java.lang.StackOverflowError for n=1000 on macOS.

Should unnamed vars (eg created by with-local-vars) print to #clojure/var nil or throw an exception? (exception is the print-dup behavior)

I think the vartag2.patch has an issue in that the test for print-var-tagged in missing an assertion. I think it is supposed to have something like:

(is (and ...))

within the last let-binding.

Printing unnamed vars has little utility (nothing distinguishes them from each other without knowing their code context), seems like it would be fine to have #clojure/var nil or #clojure/var :unnamed

OSX 10.12.6
https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0/clojure-1.8.0.jar

Incidentally, first notice using using 1.10.0-alpha4. 1.8 was the first .jar I came to that didn't cause a spec related exception when attempting to run java -cp etc.

Clojure literal maps make no guarantees on entry order. Which map implementation is used is undefined and you should have no expectation about which one that is. (For maps >8 entries, you're seeing hash map used here instead as array maps are only efficient for small maps.) So, this is the expected behavior. If you really need to retain insertion order, you can do that by using the explicit `array-map` constructor.

user=> (def one-to-nine (array-map :one "One" :two "Two" :three "Three" :four "Four" :five "Five" :six "Six" :seven "Seven" :eight "Eight" :nine "Nine"))
#'user/one-to-nine
user=> (keys one-to-nine)
(:one :two :three :four :five :six :seven :eight :nine)

Since Clojure 1.9, Clojure has a dependency on two external jars and starting it with just -cp and the clojure jar will not work. You can find instructions on how to build an all-included local jar at https://clojure.org/guides/getting_started#_other_ways_to_run_clojure.

Thank you for the explanation, Alex.

java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)

[org.clojure/clojure "1.9.0"]
[org.clojure/spec.alpha "0.1.143"]

Patch provided for issue.

Can you move the code for the problem into the description and explain the problem and the change?

I can't figure out how to edit the description...

description:
In the case of a multimethod a generator is constructed for every possible dispatch value.
One is then choosen randomly without paying any attention to overrides for the dispatch-fn(key).

commit: https://github.com/bonega/spec.alpha/commit/9cb42478b52eac275d496ec29669e2bf4b3e8e1f
My patch hopefully fixes that by checking if there exists an override for the dispatch-fn.
If so a gen/bind is done to the override generator and the result is used to lookup the correct multimethod generator.

Test case: https://pastebin.com/62ZT5Zfc
The test is expected to pass.
Basically I want to generate ::obj with an overriding generator like `(gen/generate (s/gen ::obj {::obj-type #(gen/return :a)}))`.
Expected result should always be `{::obj-type :a}`.
Previously :b was possible as output even though an override was specified.

I've given you edit right for the ticket so you can make the updates...

I have updated the description.
Let me know if anything is unclear.

Clojure 1.9, 1.8, etc

Obviously the consequence of the missed equality is that you can break many other contracts

(-> (hash-map)
    (assoc Double/NaN 1)
    (assoc Double/NaN 2)
    (assoc Double/NaN 3))
;;=> {NaN 1, NaN 2, NaN 3}

(set [Double/NaN Double/NaN Double/NaN])
;;=> #{NaN NaN NaN}

Bruno Bonacci Double.NaN is not equal itself in Java – what you’re seeing is a peculiarity of Double.equals, see https://docs.oracle.com/javase/9/docs/api/java/lang/Double.html#equals-java.lang.Object- Clojure seems to be doing the right thing here.

Yes, this is the expected behavior according to the IEEE spec.

Mac OS X 10.13.2

jonathan$ java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

So, I was able to finally track this down to an actual problem where my function value returned from the function under test would throw and exception on a particular input.

This patch helps point people in that direction (although an even better one would be to surface/explain the underlying failure rather than just allude to it).

Anyone going to respond to this? What's the usual expected response time for feedback on a patch/pull request?

There is not enough information here for this ticket to be actionable. If (s/valid? spec data) is false, then (s/explain-data spec data) should never be nil. The fact that you're seeing that is indication of a bug in the spec implementation, but without more info about the spec or the data, there's nothing I can do at the moment.

The "actionable" part is the submitted patch. This code is more resilient and friendly to sufferers of the issue.

The actual text of this ticket is merely a CLONE of the original (since I could not re-open or edit the original).

i.e., the only way I could submit this patch was to create a CLONE.

Jonathan, since you are on the list of Clojure contributors, I have bumped up your permissions on Clojure JIRA so you should be able to edit tickets now.

I do not think there is a 'usual time' by which tickets are responded to. It can vary by orders of magnitude, depending upon clarity and perceived criticality of the issue.

Alex would probably appreciate if the description included an example that can be evaluated in order to reproduce the problem. Often by seeing the problem, they may consider other solutions to the problem.

The patch is addressing the symptom, not the problem. We really need the spec and data value causing the issue.

The patch does exactly what it claims to do: provide better messaging for this scenario.

Unfortunately my attempt at constructing a minimal repro from scratch was not successful. I understand that you would like me to do additional work but all work that I've done up to this point is pro bono and I cannot donate any more of my time to this cause at this time.

We should discuss the merits of this patch on its own-- is it an improvement over the previous code or not? [And static human analysis of the code can determine that it is in fact an improvement]. The root "problem" here is that `s/valid?` and `s/explain-data` are not pure, total functions-- they can fail probabilistically depending on the arguments (i.e., when there is a higher-order function involved [which due to a fundamental limitation of spec can only be "verified" by passing random data through it]). In fact, I cannot imagine any better way to address this issue given that limitation (except bubbling up the exception which was certainly swallowed in my original, real-world reproduction of this but which was not in my attempt at the minimal repro).

I would appreciate a response to the provided reasoning.

Without a reproduction case, I'm afraid this will not move forward. If there is an invariant being broken (e.g. invalid data but missing explain-data) provide a example. It doesn't have to be minimal, just needs to be reproducible.

[1] https://dev.clojure.org/display/community/Creating+Tickets
[2] https://dev.clojure.org/display/community/Developing+Patches (see Before You Code)

So, are you saying that the Clojure project does not accept bug reports that were discovered by manual human inspection? Because if it does accept such, then you should consider this bug to be a case of such.

Also, if you would allow yourselves to merely think about the two functions in question, you can "discover" the bug for yourselves. Do you accept that `s/explain-data` and `s/valid?` are not purely deterministic? i.e., they can return different results than both each other and themselves given the exact same input on two successive runs. If you do accept this, then you have convinced yourselves of the validity of this bug claim (and I strongly urge you to accept that because it is the reality of the situation).

I am trying to help you formulate a better, actionable ticket. I don't speak on behalf of 'the Clojure project'. I implore you to tone down the antagonism. Language like "if you would allow yourselves to merely think about the two functions in question" doesn't belong here.

I don't doubt that you've uncovered an issue, but as it stands this is unactionable.

I think you should go back and re-read my previous message. Imagine that it were spoken calmly, plainly and matter-of-factly because that is how it was written/intended (instead of however you have chosen to read it). Also, it was not new information— merely a rewording of previous communications (which do not seem to have been understood).

And I really do not appreciate the sanctimonious, condescending, patronizing in your previous message to me. Save the moral grandstanding for somewhere more appropriate (wherever that may be). It has no place in a technical bug report.

Regarding the non-determinism, that's a known issue being tracked in CLJ-1949. Assuming that's addressed, I don't see the need for this change. However, I'm not sure where all that would go so I'm just going to leave this ticket open and defer to later when that becomes clearer.

Ah, yes, if CLJ-1949 were fixed then this would not be an issue. Thanks for the (reasonable) explanation.

Ubuntu 16.10 - Oracle Java 8

Should consider whether this change is more appropriate in test.check or in the spec generator for any?.

It turns out that my workaround does not fully work. I literally just stumbled in the following case:

{nil {[] {NaN 0}}}

which is a conforming value for:

(s/def ::persistent-map
(s/map-of ::anything-but-NaN ::anything-but-NaN)) ;; (s/and any? (complement double-NaN?))

So basically, the inner collections can still have NaNs. So far I've got 4 specs that I've written and faced this problem on all of them.

exclude_NaN_from_any_and_some_generators.patch is my attempt at addressing this by preventing NaNs from appearing in any? and some? generated values. It seemed to solve the problem in my testing.

There is more than a decorative difference between lists and vectors!

This does not seem like a doc bug. The transducer flavor of the function fails to meet a well-stated contract.

In the alternative, that it is just a doc bug and it's OK for partition-all to produce lists sometimes and vectors sometimes, based on a subtle configuration of your program, which you might change for computational reasons, with the nature of the returned structures farthest from your mind, thereby inadvertently up-ending all of your downstream conj's... then the doc bug is essentially that the docs have, all these years, over-stated an internal implementation detail by promising lists, and the safe way to consume the result of partition-all would be with sequence functions only.

Probably a missing delay in the alias case - there's another ticket that has the same cause.

Looks like it might be because gensub looks for matching overrides by calling spec-name, which returns the wrong value for spec aliases.

(require '[clojure.spec :as s])
(s/def ::original number?)
(s/def ::alias ::original)
(@#'clojure.spec/spec-name (s/get-spec ::alias))
;; => :user/original

I've a somewhat similar issue. I think it is related.
I'm trying to do something like :

(require '[clojure.spec.alpha :as s])
(require '[clojure.spec.gen.alpha :as gen])
(s/def ::bar any?)
(s/def ::foo (s/with-gen any? (fn [] (s/gen ::bar))))
(gen/generate (s/gen ::foo {::bar (fn [] (s/gen int?))}))

I'm somewhat expecting it generates me an integer like it would have with a direct aliasing to ::bar in ::foo definition. But it doesn't and keep the with-gen binded generator.
Is that the same issue or is that an expected behaviour or should i fill a new issue ?

I think I'm probably running into this, except that there seems to be some non-determinism involved.

It seems to behave differently, depending on whether I run it from within a deftest or from the REPL. (Running it from the REPL seems to fail every time. Running it inside deftest seems much more reliable).

My really long-winded description is at https://groups.google.com/forum/#!topic/clojure/zPWPmQGm94w

The sample where I tried to document exactly what I'm seeing is at https://gist.github.com/jimrthy/21851c52a8cd6b04a31ed08b1d0a7f04 (when I wrote that, running inside deftest seemed to work every time. That is not the case).

If nothing else, it would be nice to have better error messages that include the name of the spec it's failing to generate. Actually, that would be generally helpful and possibly worth its own ticket. Please let me know if you'd like me to create one.

Actually a completely different argument might be a better non-breaking idea.

Basically I had completely missed the call to read-string at https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/server.clj#L153.
After realizing that :args is already converted to Clojure data, David (Nolen) basically pushed a patch that solves the use case I was describing in the ticket. Closing.

Test failure related to CLJ-2204