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

[Moe Aboulkheir]

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 intention.  #(fn ..) is
going to create a no-arg fn which returns the explicit (fn ...) when
called.  Both # and fn turn out to be unnecessary as you're not doing
anything on top of passing through the single argument.

I have no idea if this is the cause of your error, though.

Take care,
Moe

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[mond]

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 but if I put in the transducer, that code 
throws an exception stating that the object (which I can print) is a String

(defn sse-data 
  [kafka-record] (...))

(defn matching-event
  [client-event-filter kafka-record] (...))

;-- INLINE version - works: record on ConsumerRecord
(defn kafka-proxy-handler
  [request]
  (let [client-filter (or (get (:params request) "filter") ".*")
consumer (topic-consumer "topic")
kafka-ch (chan)]
(go-loop []
  (if-let [records (.poll consumer 100)]
(doseq [record records]
  (if (matching-event client-filter record)
(>! kafka-ch (sse-data record)
  (recur))
{:status  200
 :body(s/->source kafka-ch)}))

;-- TRANSDUCER version - fails: says method .offset does 
not exist on String 
(defn kafka-proxy-handler
  [request]
  (let [client-filter (or (get (:params request) "filter") ".*")
consumer (topic-consumer "topic")
kafka-ch (chan 1 (comp (map #(fn [kr] (sse-data kr)))
   (filter #(fn [kr] (matching-event 
client-filter kr)]
(go-loop []
  (if-let [records (.poll consumer 100)]
(doseq [record records]
  (>! kafka-ch record)))
  (recur))
{:status  200
 :body(s/->source kafka-ch)}))


Is that the same thing or have I made a(nother) / different mistake?

Cheers

Ray


On Friday, 26 August 2016 02:02:24 UTC+2, tbc++ wrote:
>
> I'm not sure I've ever addressed this publicly, so I assume now's as good 
> a time as ever. 
>
> The reason the go block stops at function boundaries, is that changing a 
> function to be "async" changes it return type. With code transforms like 
> these a function that performs a parking take on a channel no longer 
> returns a object, it returns a "async object" that eventually returns an 
> object. Notice the difference here: 
>
> (fn [c]
>   (
> (fn [c]
>   (go (
> Adding the "go" to the function (which is required to kick off the 
> transformation) changes the return type to being a channel of objects 
> instead of a single object. This is surfaced in other languages as well 
> that support parking behavior. Performing an async/await operation in C# 
> for example changes the type from "Object" to "Task". In essence, 
> parking is infectious. Any function that calls an async function must 
> itself either become blocking or parking.
>
> For example, for this code to work:
>
> (go (vec (map 
> You would have to transform all the code in map, persistent vectors, seqs 
> and a few other bits of code. 
>
> Now there are some languages/libraries that support this behavior on the 
> JVM, two are Erjang and Pulsar. Both of these provide this functionality 
> via whole program code transformation. That is to say they perform 
> async/go-like transforms to all the code in the JVM, or at least all the 
> code that interfaces with async code. I consider this a valid approach, but 
> it is rather invasive. As such, we made a design decision early on in the 
> development of core.async to only perform local transformation. 
>
> Hopefully that provides some context. 
>
> Timothy
>
> On Thu, Aug 25, 2016 at 5:29 PM, Kevin Downey  > wrote:
>
>> The analysis for the go macro to determine that the fn never escapes the
>> go block is not something core.async does. Because of that functions are
>> sort of a black box to the transforms the go macro does.
>>
>> http://dev.clojure.org/jira/browse/ASYNC-93 is a declined issue
>> regarding this. http://dev.clojure.org/jira/browse/ASYNC-57 is another
>> similar declined issue.
>>
>> On 08/25/2016 04:21 PM, 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
>> > buff ""]
>> > (let [line-out(fn [c b]
>> >  (>!out(apply str b (repeat (-col-width (count
>> > b))\space]
>> >   (cond
>> > (>=column col-width)
>> > (condp =state
>> >   :ws (do
>> > (line-out\|buff)
>> > (recur :nl 0nil""))
>> >  ..etc etc
>> > |
>> >
>> > I just changed the line-out call to just do...
>> >
>> > |
>> > (>!out-chan buff)
>> > |
>> >
>> > ...and it worked fine.
>> >
>> > So the failing code is both dynamically and lexically within the scope
>> > of the go-loop --- is that supposed to be that way? Or am I completely
>> > missing something?
>> >
>> > -kt
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to thi

[ANN] io.aviso/rook 0.2.0

[Howard Lewis Ship]

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 power
of Pedestal.

https://github.com/AvisoNovate/rook


-- 
Howard M. Lewis Ship

Senior Mobile Developer at Walmart Labs

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: ClojureScript 1.9.225, cljs.spec fixes

[David Nolen]

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
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.225"]
>
> A bug fix release for cljs.spec and a REPL regression.
>
> As always feedback welcome!
>
> ## 1.9.225
>
> ### Fixes
> * CLJS-1759: Errors writing transit analysis cache if parallel build
> * CLJS-1760: Self-host: test-cljs-1757 failing in test-self-parity
> * CLJS-1751: port fix lost type hints in map destructuring
> * CLJS-1756: Add test.check JAR to the bootstrap script
> * CLJS-1757: cljs.spec/exercise-fn doesn't work when passed a quoted symbol
> * CLJS-1754: Add boolean? generator
> * fix REPL regression which removed warnings
>
>

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gary Trakhman]

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 (clojure.core.async/to-chan (range 10))
  ch2 (clojure.core.async/chan 2 (partition-all 2))]
  (clojure.core.async/pipe ch ch2)
  (clojure.core.async/ wrote:

> 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
>> buff ""]
>> (let [line-out (fn [c b]
>>  (>! out (apply str b (repeat (- col-width (count
>> b)) \space]
>>   (cond
>> (>= column col-width)
>> (condp = state
>>   :ws (do
>> (line-out \| buff)
>> (recur :nl 0 nil ""))
>>  ..etc etc
>>
>> I just changed the line-out call to just do...
>>
>> (>! out-chan buff)
>>
>> ...and it worked fine.
>>
>> So the failing code is both dynamically and lexically within the scope of
>> the go-loop --- is that supposed to be that way? Or am I completely missing
>> something?
>>
>> -kt
>>
>> --
> 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.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Rick Moynihan]

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 failing predicate really doesn't help much identifying
> the problem. However Leon's investigations hopefully will help to make that
> better by more precisely identifying the failing predicate.
>

Yes the failing predicate isn't always very enlightening, and something
like Leon's suggestion seems to match my intuitions about being more
accurate, more frequently - though I'll leave judgement on that to people
who know this stuff much better than I.


> I'd envisioned the source text for a particular top-level form only being
> held for as long as required to eval or compile the form, not being stored
> permanently in metadata.
>

Yes, this occurred to me only after reading your response to Alex.  That
could be pretty cool, but might require extra specialisation for the macro
case.


> But I'd have to go and look at the code to see if that's feasible or not.
> AOTing would not be a problem since the macroexpansion errors would be
> found when the form was AOTed, those errors would never occur at runtime.
>

Sounds feasible then...

Thanks for the kind words about Cursive too, one of my main goals is to
> make Clojure more approachable (hence the obsession with error messages),
> so I'm glad it's helped your co-workers! And you never know, maybe you'll
> like it enough one day to switch :-)
>

Well the biggest barrier to me trying to use it more are the lack of Emacs
& CIDER & Emacs paredit style keybindings.  I'm not sure if you can easily
share those configs with intellij; but if there was a config that had all
that together I'd probably be able to last more than 5 minutes without
getting frustrated... A discussion for another thread perhaps...

R.



>
> On 26 August 2016 at 21:15, Rick Moynihan  wrote:
>
>> 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
>>> extra effort.
>>>
>>
>> Well it was really just 5-10 minutes work.  I think it shows though that
>> specs errors are actually better than a lot of people are giving them
>> credit for.  Once I'd tidied it up a bit it surprised me.
>>
>>
>>> 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
>>> such that it either caches the program text from each top-level form as it
>>> reads it, or perhaps re-reading the file on an error. This means the
>>> relevant code is likely to look more familiar to the user, and also avoids
>>> any need to pretty print. Pretty printing is likely to be complicated since
>>> it normally works top-down, and uses the type of each form to decide how to
>>> lay its sub-parts out. If you're only pretty-printing a fragment from
>>> within, say, a large ns form, pprint is unlikely to format it as the user
>>> would expect.
>>>
>>
>> Yes, as I was re-rendering the error message it did occur to me that you
>> could do lots more to make it even nicer.  Capturing the source text is
>> certainly one, though mightn't there be a risk of using a large amount of
>> memory to store those metadata strings, especially if they're nested,
>> overlapping sexps.
>>
>> Re-reading the file on error would presumably only work if the file was
>> available, if it was only aot'd you'd have to either have captured the
>> source text at macro expansion time (as mentioned above) or try to lookup
>> the source for an even better error - and if it's not found fallback to a
>> pretty-pinting of the form.
>>
>> I didn't want to go too far down the road with the example, as I wanted
>> to show how much better the message could be with just a modest amount of
>> work.  The main ideas of the proposal are also independent and don't rely
>> too much on each other.
>>
>> I'm curious whether the core team plan for the formatting of these
>> strings to be a contract; or whether after 1.9.0 is released if they could
>> be flagged as experimental - with further improvements to the rendering
>> being pushed into future clojure releases?
>>
>> R.
>>
>> p.s. Colin, just wanted to say a massive thanks for Cursive!  I'm an
>> Emacs Cider user myself, but it's really helped many members of our team,
>> and I've been so impressed with the progress, that I even asked my boss to
>> buy me a copy... I think it'll still take quite a lot to get me off
>> Emacs/Cider; but you might well make it! :-)
>>
>>
>>> Cheers,
>>> Colin
>>>
>>> On 26 August 2016 at 12:59, Rick Moyni

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

[hiskennyness]

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
> buff ""]
> (let [line-out (fn [c b]
>  (>! out (apply str b (repeat (- col-width (count 
> b)) \space]
>   (cond
> (>= column col-width)
> (condp = state
>   :ws (do
> (line-out \| buff)
> (recur :nl 0 nil ""))
>  ..etc etc
>
> I just changed the line-out call to just do...
>
> (>! out-chan buff)
>
> ...and it worked fine.
>
> So the failing code is both dynamically and lexically within the scope of 
> the go-loop --- is that supposed to be that way? Or am I completely missing 
> something?
>
> -kt
>
>

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Colin Fleming]

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 problem. However Leon's investigations hopefully will help to make that
better by more precisely identifying the failing predicate.

I'd envisioned the source text for a particular top-level form only being
held for as long as required to eval or compile the form, not being stored
permanently in metadata. But I'd have to go and look at the code to see if
that's feasible or not. AOTing would not be a problem since the
macroexpansion errors would be found when the form was AOTed, those errors
would never occur at runtime.

Thanks for the kind words about Cursive too, one of my main goals is to
make Clojure more approachable (hence the obsession with error messages),
so I'm glad it's helped your co-workers! And you never know, maybe you'll
like it enough one day to switch :-)

On 26 August 2016 at 21:15, Rick Moynihan  wrote:

> 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
>> extra effort.
>>
>
> Well it was really just 5-10 minutes work.  I think it shows though that
> specs errors are actually better than a lot of people are giving them
> credit for.  Once I'd tidied it up a bit it surprised me.
>
>
>> 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
>> such that it either caches the program text from each top-level form as it
>> reads it, or perhaps re-reading the file on an error. This means the
>> relevant code is likely to look more familiar to the user, and also avoids
>> any need to pretty print. Pretty printing is likely to be complicated since
>> it normally works top-down, and uses the type of each form to decide how to
>> lay its sub-parts out. If you're only pretty-printing a fragment from
>> within, say, a large ns form, pprint is unlikely to format it as the user
>> would expect.
>>
>
> Yes, as I was re-rendering the error message it did occur to me that you
> could do lots more to make it even nicer.  Capturing the source text is
> certainly one, though mightn't there be a risk of using a large amount of
> memory to store those metadata strings, especially if they're nested,
> overlapping sexps.
>
> Re-reading the file on error would presumably only work if the file was
> available, if it was only aot'd you'd have to either have captured the
> source text at macro expansion time (as mentioned above) or try to lookup
> the source for an even better error - and if it's not found fallback to a
> pretty-pinting of the form.
>
> I didn't want to go too far down the road with the example, as I wanted to
> show how much better the message could be with just a modest amount of
> work.  The main ideas of the proposal are also independent and don't rely
> too much on each other.
>
> I'm curious whether the core team plan for the formatting of these strings
> to be a contract; or whether after 1.9.0 is released if they could be
> flagged as experimental - with further improvements to the rendering being
> pushed into future clojure releases?
>
> R.
>
> p.s. Colin, just wanted to say a massive thanks for Cursive!  I'm an Emacs
> Cider user myself, but it's really helped many members of our team, and
> I've been so impressed with the progress, that I even asked my boss to buy
> me a copy... I think it'll still take quite a lot to get me off
> Emacs/Cider; but you might well make it! :-)
>
>
>> Cheers,
>> Colin
>>
>> On 26 August 2016 at 12:59, 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 would
>>> make a big difference to legibility.
>>>
>>> As a starter for 10, why could we not render the messages at a REPL more
>>> like this?  (Note this is basically Brian's error - re-rendered):
>>>
>>> user=> (ns such.sequences (require ))
>>>
>>> CompilerException clojure.lang.SpecException:
>>>
>>> Call to clojure.core/ns did not conform to fdef [:args] spec
>>>
>>> There was unexpected extra input in: [2]
>>>
>>> with value: (,,, (require [such.vars :as var]
>>>  [such.immigration :as immigrate])
>>>(require midje.checking.checkers.defining
>>> midje.checking.checkers.chatty
>>>

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

[Rick Moynihan]

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
> extra effort.
>

Well it was really just 5-10 minutes work.  I think it shows though that
specs errors are actually better than a lot of people are giving them
credit for.  Once I'd tidied it up a bit it surprised me.


> 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
> such that it either caches the program text from each top-level form as it
> reads it, or perhaps re-reading the file on an error. This means the
> relevant code is likely to look more familiar to the user, and also avoids
> any need to pretty print. Pretty printing is likely to be complicated since
> it normally works top-down, and uses the type of each form to decide how to
> lay its sub-parts out. If you're only pretty-printing a fragment from
> within, say, a large ns form, pprint is unlikely to format it as the user
> would expect.
>

Yes, as I was re-rendering the error message it did occur to me that you
could do lots more to make it even nicer.  Capturing the source text is
certainly one, though mightn't there be a risk of using a large amount of
memory to store those metadata strings, especially if they're nested,
overlapping sexps.

Re-reading the file on error would presumably only work if the file was
available, if it was only aot'd you'd have to either have captured the
source text at macro expansion time (as mentioned above) or try to lookup
the source for an even better error - and if it's not found fallback to a
pretty-pinting of the form.

I didn't want to go too far down the road with the example, as I wanted to
show how much better the message could be with just a modest amount of
work.  The main ideas of the proposal are also independent and don't rely
too much on each other.

I'm curious whether the core team plan for the formatting of these strings
to be a contract; or whether after 1.9.0 is released if they could be
flagged as experimental - with further improvements to the rendering being
pushed into future clojure releases?

R.

p.s. Colin, just wanted to say a massive thanks for Cursive!  I'm an Emacs
Cider user myself, but it's really helped many members of our team, and
I've been so impressed with the progress, that I even asked my boss to buy
me a copy... I think it'll still take quite a lot to get me off
Emacs/Cider; but you might well make it! :-)


> Cheers,
> Colin
>
> On 26 August 2016 at 12:59, 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 would
>> make a big difference to legibility.
>>
>> As a starter for 10, why could we not render the messages at a REPL more
>> like this?  (Note this is basically Brian's error - re-rendered):
>>
>> user=> (ns such.sequences (require ))
>>
>> CompilerException clojure.lang.SpecException:
>>
>> Call to clojure.core/ns did not conform to fdef [:args] spec
>>
>> There was unexpected extra input in: [2]
>>
>> with value: (,,, (require [such.vars :as var]
>>  [such.immigration :as immigrate])
>>(require midje.checking.checkers.defining
>> midje.checking.checkers.chatty
>> midje.checking.checkers.simple
>> midje.checking.checkers.combining
>> midje.checking.checkers.collection))
>>
>> Input failed spec predicate: (cat :attr-map (? map?)
>>:clauses
>> :clojure.core.specs/ns-clauses)
>>
>> When compiling: (such/sequences.clj:1:1)
>>
>> user=>
>>
>> Some things to point out:
>>
>> 1. Provide some extra context by subclassing IllegalArgumentException as
>> SpecException.  This may also help separate SpecException's from other
>> IllegalArgumentExceptions too, and help tools do something special on a
>> SpecException.
>>
>> 2. Use of new lines to break up and separate text blocks.
>>
>> 3. State that it's an fdef spec, and it was the [:args] bit of that spec
>> that failed.  By stating them together we implicitly associate [:args] with
>> fdef.  Note I'm assuming we can also capture that fdef defined this spec.
>>
>> 4. It's a bit unclear what "Extra input" means... so clarify that it was
>> unexpected.  Provide the path [2] as before.
>>
>> 5. State the failing value and pretty print it.  Note that we also elide
>> the other passing parameters with a 
>>
>> 6. As bef

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

[Colin Fleming]

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
top-level macro spec. However thinking about it, in the case you mentioned
the condition is probably passed through the two macros untouched and a
problem there would be encountered by 'if'. However in that case the
original text would still be useful since it would not have been touched
during the expansions, the problem would be detecting that the form hasn't
been modified. Similarly, the 'then' expression of the 'if' would be the
original forms from the when-let body wrapped in a do.

I'm not sure how useful this idea would be in practice, it would need some
experimentation to see how well it works.

On 26 August 2016 at 20:24, Alex Miller  wrote:

> 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
>> such that it either caches the program text from each top-level form as it
>> reads it, or perhaps re-reading the file on an error. This means the
>> relevant code is likely to look more familiar to the user, and also avoids
>> any need to pretty print. Pretty printing is likely to be complicated since
>> it normally works top-down, and uses the type of each form to decide how to
>> lay its sub-parts out. If you're only pretty-printing a fragment from
>> within, say, a large ns form, pprint is unlikely to format it as the user
>> would expect.
>>
>
> Does the caching or file re-reading have any hope of working when you have
> nested macro expansions (like when-let -> when -> if)? The input to when in
> that case is a form constructed by when-let, not text sitting in a file.
> But maybe that doesn't matter if it's still useful for some good percentage
> of macro calls that have access to text. One benefit of using pprint is
> that you (the user) can control stuff like *print-length*,
> *print-suppress-namespace*, *print-right-margin*, etc.
>
> --
> 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.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alex Miller]

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 
> such that it either caches the program text from each top-level form as it 
> reads it, or perhaps re-reading the file on an error. This means the 
> relevant code is likely to look more familiar to the user, and also avoids 
> any need to pretty print. Pretty printing is likely to be complicated since 
> it normally works top-down, and uses the type of each form to decide how to 
> lay its sub-parts out. If you're only pretty-printing a fragment from 
> within, say, a large ns form, pprint is unlikely to format it as the user 
> would expect.
>

Does the caching or file re-reading have any hope of working when you have 
nested macro expansions (like when-let -> when -> if)? The input to when in 
that case is a form constructed by when-let, not text sitting in a file. 
But maybe that doesn't matter if it's still useful for some good percentage 
of macro calls that have access to text. One benefit of using pprint is 
that you (the user) can control stuff like *print-length*, 
*print-suppress-namespace*, *print-right-margin*, etc.

-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.