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

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 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 a big win for not much > extr

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 probl

Re: Why is this not considered to be in a go block?

Doesn't work in a FOR loop either. Thank god for LOOP! :) -kt On Thursday, August 25, 2016 at 7:21:20 PM UTC-4, hiskennyness wrote: > > I am getting an error about >! not being in a go block with this code: > > (go-loop [state :nl > column 0 > last-ws nil >

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 your > version is that the faili

Re: Why is this not considered to be in a go block?

I wouldn't expect it to work in a `for` comprehension, because that's combining laziness (which uses function thunks under the hood) with the async state machines. In general, you shouldn't do side-effects in a `for`, though I'd be surprised if you couldn't take at the input. This works (let [ch

Re: ANN: ClojureScript 1.9.225, cljs.spec fixes

I just cut 1.9.227. The only change was a warning regression around cljs.core excludes David On Fri, Aug 19, 2016 at 1:40 PM, David Nolen wrote: > ClojureScript, the Clojure compiler that emits JavaScript source code. > > README and source code: https://github.com/clojure/clojurescript > > Lein

[ANN] io.aviso/rook 0.2.0

io.aviso/rook has undergone a full rewrite, keeping its essence, but aligning with Pedestal. Rook is a library that makes it easy to map namespaces, and functions within those namespaces, as endpoints in a Pedestal application. You end up with far less configuration without sacrificing any of the

Re: Why is this not considered to be in a go block?

The flood gates are open Timothy! and on the back of that, I'm gonna dump some code in here so pls excuse me - it's on GitHub too so maybe look there if it's too heavy for email. I have this code in the go-loop

Re: Why is this not considered to be in a go block?

On Sat, Aug 27, 2016 at 12:08 AM, mond wrote: > Is that the same thing or have I made a(nother) / different mistake? > > At a glance, it looks like the functions you're passing into map and filter are shaped wrong - (comp (map sse-data) (filter matching-event-client-filter)) may have been the int