Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On 26 August 2016 at 10:31, Colin Fleming wrote: > I agree that tidied up the error messages are much more understandable. > Replacing things like "path" with a description of what it means goes a > long way. My main issue with the original error which persists in

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I agree that tidied up the error messages are much more understandable. Replacing things like "path" with a description of what it means goes a long way. My main issue with the original error which persists in your version is that the failing predicate really doesn't help much identifying the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On 26 August 2016 at 03:11, Colin Fleming wrote: > Hi Rick, > > That looks really excellent, and is a huge improvement. Particularly in > combination with Leon's proposed change which more precisely identifies the > likely failing part of the grammar, this looks like

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I'm not sure about that - I suspect it would still be useful even just for surface forms, although it's probably not ideal to have two different modes for when you have the data or not. I had assumed that, assuming that most macro forms are spec'ed, most syntax problems would be encountered by the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Thursday, August 25, 2016 at 9:11:39 PM UTC-5, Colin Fleming wrote: > > > One thing that I think would help a lot would be if it were possible to > show the actual text from the failing expression rather than pretty > printing a seq representation of it. This would mean modifying the reader

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Hi Rick, That looks really excellent, and is a huge improvement. Particularly in combination with Leon's proposed change which more precisely identifies the likely failing part of the grammar, this looks like a big win for not much extra effort. One thing that I think would help a lot would be

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Thanks, Adrian. I'm unsure about the disrespectful part - as I mentioned, discussions around community problems are always difficult, but they are important. As with all internet conversations, of course, tone is everything. But since this is very well-trodden ground, and for whatever reason it's

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Thursday, August 25, 2016 at 8:00:37 PM UTC-5, Rick Moynihan wrote: > > I think one obvious area that specs error messages could be improved is > with some basic formatting and cosmetic changes. If spec presented errors > not as a wall of text and syntax but with some simple formatting it

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I think one obvious area that specs error messages could be improved is with some basic formatting and cosmetic changes. If spec presented errors not as a wall of text and syntax but with some simple formatting it would make a big difference to legibility. As a starter for 10, why could we not

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Colin, FWIW, I think you're doing a great job of articulating your points (which I largely agree with) and are providing great feedback for the core team and community to think about. This conversation is supposed to happen as the alpha versions are being iterated on. But I think continually

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> > I really don't understand how you expect anyone to take your criticism > seriously if you keep implying you're happily abandoning the language for > greener pastures. > Why would anyone developing Clojure look at anything you have to say at > this point as anything less than trolling?

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Hi Gary, Re the documentation: A lot of people have worked to make clojure.org better, including changing the contribution model to be both easier and more familiar. That said, I don't doubt that is could be a lot better. In particular, the guides section could expand to cover a lot of the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

After further consideration, I would like to back off the word: "abomination". I have strong opinions about code, and strong opinions about technical aspects of Midje, but I chose the wrong word in my original statement. The technical definitions of words do not matter as much as the connotations

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

>> I also note that my library, Midje, is typically insulted on this mailing list whenever a newbie brings it up. One of the contributors to this thread has called it “an abomination”. There was no similar concern about *his* tone. Because, I suspect, he's on the inside, punching out. Yes, that

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Over the years I've kind of started agreeing with what Brian's saying. Much as I love/know clojure and the philosophy that bears its fruit, I think spec's sideband error-handling is a great low-risk opportunity to build in some 'easy'. My team is moving from rails towards elixir after having

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Thursday, August 25, 2016 at 10:46:14 AM UTC-5, adrian.med...@mail.yu.edu wrote: > > I really don't understand how you expect anyone to take your criticism > seriously if you keep implying you're happily abandoning the language for > greener pastures. > > Why would anyone developing Clojure

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Brian, your concerns have been heard. Please keep in mind this is a work in progress and that there is ongoing work that is not yet visible. While I don't expect that the final endpoint of this work will be exactly what you would design (or what you might see in other languages as our goals

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I really don't understand how you expect anyone to take your criticism seriously if you keep implying you're happily abandoning the language for greener pastures. Why would anyone developing Clojure look at anything you have to say at this point as anything less than trolling? Back on

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 24, 2016, at 9:28 PM, adrian.med...@mail.yu.edu wrote: > > I do not think your tone and lack of constructive feedback to Alex's (and > others) thoughtful responses is helping your case. Probably not(*), though I would characterize the responses differently. They are polite, and

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Hi Brian, Not crazy at all! Spec errors are maps at the bottom, and IMO these maps should flow anywhere we are making exceptions. This is already true for the exceptions coming from spec.test, and we should make it true for the macroexpand exceptions as well. (I actually prefer reading the map

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Brian, The tone of your previous post is not constructive. Let's keep the discussion about ideas, not people. Thanks, Stu On Wed, Aug 24, 2016 at 8:46 PM, Brian Marick wrote: > > On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote: > > 3.

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I do not think your tone and lack of constructive feedback to Alex's (and others) thoughtful responses is helping your case. On Wednesday, August 24, 2016 at 8:46:47 PM UTC-4, Brian Marick wrote: > > > On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote: > > 3. "Follow

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 24, 2016, at 7:46 PM, Brian Marick wrote: > So why not do it in the bottom layer? Is there some deep reason why only an > unserious programmer would want information in anything other than the > current clojure.spec order? (We’re talking here about reordering

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote: > > 3. "Follow the inverted pyramid so people see what is most important." This > kind of thing is easily done in a layer above spec, e.g. a custom REPL > printer for spec macro errors. Worth working on but

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

This is almost exactly the intuition behind the standard error reporting heuristic for grammars involving alternations. It is a heuristic, but it has to be since on a failure it's impossible to entirely accurately determine the user's intention. But intuitively, generally the rule that has managed

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Hi Alex, I could track down why explain stops early. http://dev.clojure.org/jira/browse/CLJ-2013 On Wednesday, August 24, 2016 at 11:33:43 PM UTC+2, Leon Grapenthin wrote: > > > On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote: >> >> predicate: (cat :args (*

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote: > > predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (? > (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))), > > the predicate that is actually failing in the spec, probably not >

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Hi Beau, Yes. Nevermind and everyone should learn to read spec. :-) That said, such customizations allow people to experiment and flesh out a bunch different ideas in parallel. Best, Stu On Wed, Aug 24, 2016 at 1:17 PM, Beau Fabry wrote: > Just specifically on a custom

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Just specifically on a custom REPL printer, wouldn't that negate the benefits Alex sees in people becoming accustomed to reading spec error messages? If every error report from each different environment potentially looks different? Also, from the position of a community maintainer Brian is

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

A suggestion for making all errors better would be to give not only the precise file and line _of the beginning of the top level form containing the problem_, but a more precise line and column of _the part of the form that spec is complaining about_. Multi-line forms are the biggest and hardest

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Brian originally raised 5 points that were concrete & specific, and therefore potentially actionable. That is usefully-shaped feedback, thanks Brian! My take on those points, which I will recast in my own words: 1. "Loosen rules about ns form to match what people have actually done." This is

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Sure, at the end of the day I don't really care about thre require/:require issue, it just seems a little incongruent with previous decisions which have promoted backwards compatibility. I generally prefer increased strictness, so I'm fine with the change. I do care about the error messages,

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I agree Colin, this feels more like the beatings shall continue until morale improves ;-) More seriously, I understand the point of the musical instruments analogy to be a reminder to programmers that learning a language and understanding it in depth will increase your power and expressivity

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I'm not anywhere near as deep into spec as would be needed to fully understand this thread, but I will say that I agree with those who object to the guitar analogy. That argument would work just as well as a response to someone who complained about the difficulty of C++, or assembler, or APL.

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> > But creating error messages that are optimal for a user with no knowledge > or Clojure or spec is just not the goal. This is a totally false dichotomy. No-one in this thread is asking for that. This thread has several examples of expert Clojure users for whom the error messages are

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

While I think the spec errors are pretty unfriendly, it's probably worth remembering that most of the times you'll get one you would have got an inscrutable ClassCastException or incorrect behaviour from a totally different place in the codebase prior to spec. It's definitely a huge

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

The path is the series of tags you've traversed through the spec (when there are parts in :or :alt :cat etc). We will have more documentation on it but we've held off because it was changing pretty regularly in early alphas. A spec for the current explain-data is something like this (I'm just

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Tue, Aug 23, 2016 at 7:45 AM, Alex Miller wrote: > We expect Clojure users to become familiar with spec and its output as it > is (now) an essential part of the language. You will see specs in error > messages. > Is there any documentation to help users understand how to

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

>> It certainly doesn't require a 200MB jar, more like 300 lines of code, including the parser itself. I completely agree, what I'm saying is, if you start supporting my laundry list of phonetic, spelling, and structural suggestions, your codesize will quickly get much larger than 300 lines. On

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

The error message I posted earlier comes right out of the parser with very little infrastructure on top of it. It certainly doesn't require a 200MB jar, more like 300 lines of code, including the parser itself. On 24 August 2016 at 02:21, Timothy Baldridge wrote: > So

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On 8/23/16, 7:45 AM, "Alex Miller" wrote: > I'm absolutely not talking about making something hard on purpose > and I'm not saying that making things easy to learn is bad. I'm > stating an ordering of priorities. …and this is why I

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

As some other people have stated: Its way, way premature to start worrying about the exact format of error messages. Given the facilities spec provides, its clear as day that vastly better messages can be built on top. Or even forget messages: syntax highlighting or source-code presentation can

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I do not have an idea of what the final end point will look like exactly. I don't get the feeling that there is any answer that you will find satisfying, so I'm not sure what else I can do for you. We expect Clojure users to become familiar with spec and its output as it is (now) an essential

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

So personally, I don't want extremely accurate suggestions in the core of Clojure. Why? Because I think they will never go far enough and I have a ton of features I want to see that can't (shouldn't) be in the core of a language. I'll never forget the first undefined symbol I got in Clang after

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 22, 2016, at 7:50 PM, Alex Miller wrote: > You've complained in other channels about the "learning to read" error > messages part and I think you've taken it entirely the wrong way or maybe I > just disagree. There are benefits from reporting errors in a generic,

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Tuesday, August 23, 2016 at 2:58:42 AM UTC-5, Andy Fingerhut wrote: > > In the data representing fragments of the user's code returned with these > macro errors, does it include metadata with :line and :column keys in it? > No, although the exception itself from macroexpansion will have the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

In the data representing fragments of the user's code returned with these macro errors, does it include metadata with :line and :column keys in it? Perhaps that would be one way to give errors localized to particular places in the user's code. It isn't always available, e.g. keyword cannot have

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Sorry, I missed this one in the thread somehow. This happens to be a case where you have *both* defn and destructuring specs in play, so it has even greater potential for confusion in generic errors. On Monday, August 22, 2016 at 11:23:33 AM UTC-5, Leon Grapenthin wrote: > > I welcome the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> > The big syntax macro cases like ns or let are way past the "average" spec. > ... I don't think it's fair to judge the general performance of spec's > errors on just those use cases. It might be true that these macros are larger than usual, but they're also the cases that everyone will

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Monday, August 22, 2016 at 7:43:53 PM UTC-5, Colin Fleming wrote: > > I agree that the ability to get a machine-readable parse failure is very > important for tooling. However I feel very strongly that the error messages > that are printed by default on macro validation failures should be

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Monday, August 22, 2016 at 6:45:16 PM UTC-5, Oliver George wrote: > > > I'm interested to see any discussion regarding this point. No doubt > translating spec data into more friendly formats has been discussed. > > Getting the data right is clojure's problem. That's the concrete >

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I've already mentioned most of this above, but I'll try again. In short, I'd say yes (that's why we are still in alphas), but in adherence with the general goals we have of capturing and returning comprehensive data about the error and building those error messages generically. - Getting the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I agree that the ability to get a machine-readable parse failure is very important for tooling. However I feel very strongly that the error messages that are printed by default on macro validation failures should be easily understandable, and the current ones are not. If we completely punt to

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I'm interested to see any discussion regarding this point. No doubt translating spec data into more friendly formats has been discussed. Getting the data right is clojure's problem. That's the concrete foundation and building blocks required for tooling. Seems like Rich has done

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 22, 2016, at 11:23 AM, Leon Grapenthin > wrote: > > Still the error messages are simply far from good enough and that is what > appears to me as the main problem OP has. This is important. Will the new, stricter error messages be improved before 1.9 is

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I welcome the strict checking over backwards compatibility for broken syntax. E. g. allowing things like symbols in the ns decl would require supporting that as a feature in future updates, analyzer code, other hosts etc. The Clojure devs should not have to worry things with so little use.

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I've added library related fixes related to core specs to an info page at: http://dev.clojure.org/display/design/Errors+found+with+core+specs On Sunday, August 21, 2016 at 8:24:20 PM UTC-5, Alex Miller wrote: > > On Sunday, August 21, 2016 at 5:28:57 PM UTC-5, lvh ‌ wrote: >> >> FYI, while I

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

That emacs joke gets my week started with some abdominal pain  I support strictness  Luc P. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Sunday, August 21, 2016 at 5:28:57 PM UTC-5, lvh ‌ wrote: > > FYI, while I disagree with your conclusion (I think we should go fix > libraries instead), I ran into the same issue just now for roughly the same > reason, except the thing that pulled in an old version of core.unify was >

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Sunday, August 21, 2016 at 5:25:03 PM UTC-5, Brian Marick wrote: > > As an update. I’ve fixed the `ns` oopsie in Suchwow (one file), and the > coincident `ns` oopsie in Midje (one file). But this happens when running > Midje’s self-tests against Clojure 1.9alpha11: > > > Exception in

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

FYI, while I disagree with your conclusion (I think we should go fix libraries instead), I ran into the same issue just now for roughly the same reason, except the thing that pulled in an old version of core.unify was core.typed, which pulls in 0.5.3 through core.contracts. > On Aug 21, 2016,

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

As an update. I’ve fixed the `ns` oopsie in Suchwow (one file), and the coincident `ns` oopsie in Midje (one file). But this happens when running Midje’s self-tests against Clojure 1.9alpha11: > Exception in thread "main" java.lang.IllegalArgumentException: Call to > clojure.core/fn did not

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

The documentation now includes the spec, which would explicilly mention the symbol, so this would not be tacitly hidden as you suggest. David is already working on porting these specs to ClojureScript so that issue is one we will imminently face. So again I will state: while the current spec

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I couldn't help myself... https://xkcd.com/1172/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post.

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I'd prefer getting rid of the symbol option. Some kind of deprecation warning for a version or two might be an idea though. On Sat, Aug 20, 2016, 10:51 PM Sean Corfield wrote: > Or keep the stricter compiler and: > > 1. People who want to port to clojurescript will incur

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Or keep the stricter compiler and: 1. People who want to port to clojurescript will incur exactly the same cost as they do now. **2. People who don’t want to port to clojurescript and don’t want to move to Clojure 1.9 will incur no additional cost. 3. Clojurescript maintainers will incur no

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On 8/20/16, 7:13 PM, "Colin Fleming" wrote: > in this case it seems like the change breaks a lot of existing code I disagree. Compared to the vast amount of Clojure code out there, I would contend that this breaks very little

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

What about a compromise where you could opt-in or opt-out of checking macro specs at compile time (via a compiler option)? It seems worth preserving the correctness of the spec, without forcing all of the breakage. Andrew Oberstar On Sat, Aug 20, 2016 at 9:13 PM Colin Fleming

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I think there's considerable scope to produce better error messages automatically than what spec produces, and I hope that can happen for 1.9. The error message produced by the code I demoed at the conj last year would be: Unexpected symbol 'require' at while parsing namespace clauses. Expected

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

With respect to preserving undocumented behaviour, while in general I'm in favour of making compilers stricter, in this case it seems like the change breaks a lot of existing code in ways that are impossible for library consumers to fix themselves - they have to wait for an update to the library,

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 6:30 PM, Timothy Baldridge wrote: > > Brian, let's make it more concrete then...why should the Clojure compiler > continue to support undocumented features that make code unportable? Because: 1. People who want to port to clojurescript will incur

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

Brian, let's make it more concrete then...why should the Clojure compiler continue to support undocumented features that make code unportable? On Sat, Aug 20, 2016 at 4:48 PM, Brian Marick wrote: > > On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote: > > I disagree

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote: > > I disagree (strongly) with your position here Brian. I’ll try to explain > clearly why but first a little background… I too have felt the pain of having to maintain backward compatibility. However, I’m reminded, in this case, of Mark

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

s, warts, and surprising behavior. I > wouldn’t wish that on any sane developer. > > > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org > > > > *From: *Brian Marick <mar...@roundingpegs.com> > *Sent: *Saturday, August 20, 2016 7:58 AM &

RE: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

I disagree (strongly) with your position here Brian. I’ll try to explain clearly why but first a little background… At World Singles, we’ve always done multi-version testing against the stable version of Clojure that we plan to use in production and also against the very latest master

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Saturday, August 20, 2016 at 9:58:14 AM UTC-5, Brian Marick wrote: > > > On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > We discussed this before releasing the specs and decided to start on the > strict side. That said, this is still an alpha and there is plenty of

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Saturday, August 20, 2016 at 9:40:21 AM UTC-5, Brian Marick wrote: > > > On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > You left out this next important line too since it points you to exactly > the file and line where the error occurs: > > ,

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > We discussed this before releasing the specs and decided to start on the > strict side. That said, this is still an alpha and there is plenty of time to > change our minds prior to official release of 1.9 if that ends

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote: > > You left out this next important line too since it points you to exactly the > file and line where the error occurs: > > , compiling:(such/sequences.clj:1:1) This is interesting. Here’s why I missed it. I attach the

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

On Saturday, August 20, 2016 at 5:17:59 AM UTC-5, Brian Marick wrote: > > Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out > to have been a use of `ns …(require…` instead of `(ns …(:require`. Not in > Suchwow, but in Midje. Unfortunately, the Suchwow file the bug