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

[Colin Fleming]

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

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 before state the predicate that identified the failure in a
> humanised manner and the location of the failing form.
>
> I'm not suggesting these are necessarily good ideas, and I appreciate I've
> not considered all of the other cases you might need to, but it seems that
> something like the above would be a dramatic if entirely cosmetic
> improvement.  It would be a shame if clojure.core made no attempt to
> humanise the display of these messages and left it entirely up to the
> community.
>
> Thoughts?
>
> R.
>
>
> On 20 August 2016 at 15:03, Alex Miller  wrote:
>
>>
>>
>> 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 report
>>> pointed at *also* had that typo - apparently I am prone to it - so adding
>>> the colon to the require there didn’t make the problem go away.
>>>
>>> That caused me to lose my temper and make a fool of myself, which is
>>> neither here nor there, except that I apologize to @puredanger.
>>>
>>> I have two suggestions, though:
>>>
>>> 1. It has long been the case that Clojure allowed `(ns (require…)` even
>>> though that’s strictly incorrect. I suggest that, for backwards
>>> compatibility, it be allowed going forward. That is, I think it does no
>>> harm for a correct `ns` statement to allow symbols as well as keywords.
>>> That wrong code in Midje has been there since Clojure 1.2.
>>>
>>
>> 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 

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

[Colin Fleming]

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
clear it won't change, I definitely agree they're unproductive. I'll be
leaving the non-error-message aspects of this conversation alone now.

On 26 August 2016 at 12:03,  wrote:

> 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 resurfacing meta issues one has with Clojure's
> management (and I'm not saying you're doing this, but others are) instead
> of engaging thoughtfully with a team who is engaging you thoughtfully is
> both disrespectful and unproductive. Actually, it's counter productive
> because it can unfortunately make people think twice before taking you
> seriously in the future.
>
> Like you, I think friendly error messages is an important issue for
> Clojure. We have an amazing source of heavily annotated information we can
> use to generate best-in-class error messages thanks to clojure.spec. We
> should refocus this in thread.
>
> But I'm not a moderator, so I guess take whatever I say with a grain of
> salt. :)
>
> On Thursday, August 25, 2016 at 7:12:04 PM UTC-4, Colin Fleming 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 look at anything you have to say at
>>> this point as anything less than trolling?
>>
>>
>> Because if we're genuinely interested in improving the language and the
>> community around it, the people who are deliberately choosing to leave it
>> have the answers to what we need to do that.
>>
>> I develop Cursive, and I'm always very interested in feedback from users,
>> and I'm really *more* interested in feedback about what they don't like
>> because my opportunities for improvement are there. It's always nice to
>> hear that people love Cursive and those messages are an important part of
>> maintaining my motivation to continue working on it. But in terms of
>> feedback that I can directly action, problems are where it's at.
>>
>> Of course, sometimes that feedback is not useful, actionable or valuable.
>> "IDEs suck" gets ignored, in much the same way that "Clojure sucks because
>> it's dynamically typed" should. "I don't use it because I find IDE's too
>> heavy" (like "I don't use Clojure because I prefer strong types") is fine,
>> there are lots of people out there with different preferences and I can't
>> cater to everyone. Being based on IntelliJ is what Cursive *is*, and I
>> can't change that. But if someone uses Cursive a lot, likes it, talks
>> publicly about how much they like it, participates in the issue tracker and
>> on the mailing list etc etc but then says "I'm taking up Emacs because I
>> can't stand how Cursive does x, y, and z" then I will absolutely try to
>> make those things better.
>>
>> Criticisms about how the community works are perhaps the hardest to hear
>> since they seem very personal - if we're active in the community, in some
>> way they're directly criticising the ways we behave. Similarly, they're
>> much harder to fix. But they are essential, since no-one uses a programming
>> language purely because of the language itself these days.
>>
>> FWIW, I share many of Brian's concerns.
>>
>> On 26 August 2016 at 03:46,  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 look at anything you have to say at
>>> this point as anything less than trolling?
>>>
>>> Back on topic, I find Colin's suggestions about implementing an error
>>> reporting heuristic intriguing. What he has laid out could form the basis
>>> for a solution to this problem which can satisfy everyone's requirements
>>> when integrated well with spec's explain-data. I am curious to hear what
>>> Alex and others think about it.
>>>
>>> On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote:
>>>

 On Aug 24, 2016, at 9:28 PM, adrian...@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 they are intended to be helpful to someone who already
 agrees with axioms like “good error-handling is 

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

[Alex Miller]

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 would 
> make a big difference to legibility.
>

Thanks for your input, I've reached many similar conclusions and we're 
working on it.

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

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 before state the predicate that identified the failure in a humanised
manner and the location of the failing form.

I'm not suggesting these are necessarily good ideas, and I appreciate I've
not considered all of the other cases you might need to, but it seems that
something like the above would be a dramatic if entirely cosmetic
improvement.  It would be a shame if clojure.core made no attempt to
humanise the display of these messages and left it entirely up to the
community.

Thoughts?

R.


On 20 August 2016 at 15:03, Alex Miller  wrote:

>
>
> 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 report
>> pointed at *also* had that typo - apparently I am prone to it - so adding
>> the colon to the require there didn’t make the problem go away.
>>
>> That caused me to lose my temper and make a fool of myself, which is
>> neither here nor there, except that I apologize to @puredanger.
>>
>> I have two suggestions, though:
>>
>> 1. It has long been the case that Clojure allowed `(ns (require…)` even
>> though that’s strictly incorrect. I suggest that, for backwards
>> compatibility, it be allowed going forward. That is, I think it does no
>> harm for a correct `ns` statement to allow symbols as well as keywords.
>> That wrong code in Midje has been there since Clojure 1.2.
>>
>
> 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 up being
> a catastrophic decision.
>
>
>>
>> 2. The following is not a good error message:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: Call to
>> clojure.core/ns did not conform to spec:
>> In: [2] val: ((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))
>> fails at: [:args] predicate: (cat :attr-map (? map?) :clauses
>> :clojure.core.specs/ns-clauses),  Extra input
>>
>
> 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)
>
> spec produces very detailed error messages driven by the specs and the
> value being validated. I admit that in some cases the output from a spec
> error (particularly for complicated syntaxes where there are wide
> alternative fan-outs) is daunting. However, spec error messages are going
> to be increasingly common for all of us to see and understand and I think
> it is worth taking the time to slow down and actually read 

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

[adrian . medina]

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 resurfacing meta issues one has with Clojure's 
management (and I'm not saying you're doing this, but others are) instead 
of engaging thoughtfully with a team who is engaging you thoughtfully is 
both disrespectful and unproductive. Actually, it's counter productive 
because it can unfortunately make people think twice before taking you 
seriously in the future.

Like you, I think friendly error messages is an important issue for 
Clojure. We have an amazing source of heavily annotated information we can 
use to generate best-in-class error messages thanks to clojure.spec. We 
should refocus this in thread. 

But I'm not a moderator, so I guess take whatever I say with a grain of 
salt. :) 

On Thursday, August 25, 2016 at 7:12:04 PM UTC-4, Colin Fleming 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 look at anything you have to say at 
>> this point as anything less than trolling? 
>
>
> Because if we're genuinely interested in improving the language and the 
> community around it, the people who are deliberately choosing to leave it 
> have the answers to what we need to do that.
>
> I develop Cursive, and I'm always very interested in feedback from users, 
> and I'm really *more* interested in feedback about what they don't like 
> because my opportunities for improvement are there. It's always nice to 
> hear that people love Cursive and those messages are an important part of 
> maintaining my motivation to continue working on it. But in terms of 
> feedback that I can directly action, problems are where it's at.
>
> Of course, sometimes that feedback is not useful, actionable or valuable. 
> "IDEs suck" gets ignored, in much the same way that "Clojure sucks because 
> it's dynamically typed" should. "I don't use it because I find IDE's too 
> heavy" (like "I don't use Clojure because I prefer strong types") is fine, 
> there are lots of people out there with different preferences and I can't 
> cater to everyone. Being based on IntelliJ is what Cursive *is*, and I 
> can't change that. But if someone uses Cursive a lot, likes it, talks 
> publicly about how much they like it, participates in the issue tracker and 
> on the mailing list etc etc but then says "I'm taking up Emacs because I 
> can't stand how Cursive does x, y, and z" then I will absolutely try to 
> make those things better. 
>
> Criticisms about how the community works are perhaps the hardest to hear 
> since they seem very personal - if we're active in the community, in some 
> way they're directly criticising the ways we behave. Similarly, they're 
> much harder to fix. But they are essential, since no-one uses a programming 
> language purely because of the language itself these days.
>
> FWIW, I share many of Brian's concerns.
>
> On 26 August 2016 at 03:46,  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 look at anything you have to say at 
>> this point as anything less than trolling? 
>>
>> Back on topic, I find Colin's suggestions about implementing an error 
>> reporting heuristic intriguing. What he has laid out could form the basis 
>> for a solution to this problem which can satisfy everyone's requirements 
>> when integrated well with spec's explain-data. I am curious to hear what 
>> Alex and others think about it. 
>>
>> On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote:
>>
>>>
>>> On Aug 24, 2016, at 9:28 PM, adrian...@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 they are intended to be helpful to someone who already 
>>> agrees with axioms like “good error-handling is a nail for which core.spec 
>>> is the hammer” and “it is wise to push the responsibility for error 
>>> understanding to third-party libraries or diligent study”. They do a 
>>> service in that they lay out the rules under which Clojure users should 
>>> expect to live. But they are largely reiterations rather than engagement. I 
>>> find that rather frustrating.
>>>
>>>
>>> Let me point to an essential book on business/community management, 
>>> Hirschman’s /Exit, Voice, and Loyalty/. 
>>> https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and 

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

[Timothy Baldridge]

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]
  (". 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  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 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.
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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] Leiningen 2.7.0

[Chris Price]

The hope for the managed-dependencies stuff is to be able to use it in 
combination with a "parent project" definition, to consolidate version 
numbers for common dependencies.  The support for this will be released in 
the lein-parent[1] plugin, hopefully soon (once the corresponding PR[2] is 
merged), and then once that has some mileage on it it might be worth adding 
some of those capabilities in to core leiningen.

[1] https://github.com/achin/lein-parent
[2] https://github.com/achin/lein-parent/pull/6



On Thursday, August 25, 2016 at 3:06:40 AM UTC-7, Rick Moynihan wrote:
>
> Many, many thanks for this release!
>
> Also the manged-dependencies feature looks like it might be super useful.
>
> R.
>
> On 25 August 2016 at 01:03, Jean Niklas L'orange  > wrote:
>
>> Greetings, fellow Clojurians!
>>
>> I am happy to announce Leiningen 2.7.0! This release contains mostly
>> bugfixes, but two major new improvements were added. There is now a
>> PowerShell version of `lein.bat`, and `:managed-dependencies` has been
>> added to Leiningen.
>>
>> Both improvements should be considered to be in beta, but please try
>> them out and report bugs you find in the GitHub issue tracker. The
>> rationale for `:managed-dependencies` can be found at [1].
>>
>> To replace `lein.bat` with the PowerShell equivalent, download
>> `lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If
>> you end up with an error related to `Invoke-WebRequest`, then it may
>> be a result of an old version of PowerShell, which seems to be
>> resolved by installing the Windows Management Framework 4.0 [4].
>>
>> The full list of significant user changes:
>>
>> * Add PowerShell script for Windows users. (Brian Lalonde)
>> * Run `:prep-tasks` before `lein test`, so generated test namespaces
>>   will be tested. (Martin Reck)
>> * Better error message when attempting to do `lein run` without
>>   `project.clj`. (Eduardo Seabra Silva)
>> * Add support for `:managed-dependencies`. (Chris Price)
>> * Provide the current clojars certificate. (Toby Crawley)
>> * Add `*eval-print-dup*` to evaluate forms passed to
>>   `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva)
>> * Update bash completions. (Zack Dever)
>> * Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins)
>> * Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson)
>> * Catch and handle fixture errors during `lein test`. (Alex Hall)
>> * Fix a bug where spaces in directory names on Windows caused crashes.
>>   (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange)
>> * Fix a bug where `lein search` would take forever downloading
>>   clojars.org. (Paul Dorman)
>> * Retain user defined private repositories when building jars,
>>   uberjars and deploy. (Rick Moynihan)
>> * Honor whitelist settings when `lein javac` is called via `lein jar`.
>>   (Chris Price)
>> * `lein vsc push` for git will now only push branch-related tags.
>>   (Łukasz Klich)
>>
>> Those who have manually installed Leiningen can run `lein upgrade` to
>> pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the
>> previous version if you run into any issues. Keep in mind that the
>> PowerShell script was introduced in this release, hence there are no
>> downgrade candidates for it right now.
>>
>> We have had lots of contributors help out making this release happen,
>> and I'd especially like to thank Chris Price (cprice404) and Florian
>> Anderiasch (winks) for their help with this release.
>>
>> [1]: 
>> https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md
>> [2]: 
>> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.cmd
>> [3]: 
>> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.ps1
>> [4]: 
>> http://social.technet.microsoft.com/wiki/contents/articles/21016.how-to-install-windows-powershell-4-0.aspx
>>
>> -- Jean Niklas
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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 

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

[Kevin Downey]

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


-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

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

[hiskennyness]

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


Because if we're genuinely interested in improving the language and the
community around it, the people who are deliberately choosing to leave it
have the answers to what we need to do that.

I develop Cursive, and I'm always very interested in feedback from users,
and I'm really *more* interested in feedback about what they don't like
because my opportunities for improvement are there. It's always nice to
hear that people love Cursive and those messages are an important part of
maintaining my motivation to continue working on it. But in terms of
feedback that I can directly action, problems are where it's at.

Of course, sometimes that feedback is not useful, actionable or valuable.
"IDEs suck" gets ignored, in much the same way that "Clojure sucks because
it's dynamically typed" should. "I don't use it because I find IDE's too
heavy" (like "I don't use Clojure because I prefer strong types") is fine,
there are lots of people out there with different preferences and I can't
cater to everyone. Being based on IntelliJ is what Cursive *is*, and I
can't change that. But if someone uses Cursive a lot, likes it, talks
publicly about how much they like it, participates in the issue tracker and
on the mailing list etc etc but then says "I'm taking up Emacs because I
can't stand how Cursive does x, y, and z" then I will absolutely try to
make those things better.

Criticisms about how the community works are perhaps the hardest to hear
since they seem very personal - if we're active in the community, in some
way they're directly criticising the ways we behave. Similarly, they're
much harder to fix. But they are essential, since no-one uses a programming
language purely because of the language itself these days.

FWIW, I share many of Brian's concerns.

On 26 August 2016 at 03:46,  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 look at anything you have to say at
> this point as anything less than trolling?
>
> Back on topic, I find Colin's suggestions about implementing an error
> reporting heuristic intriguing. What he has laid out could form the basis
> for a solution to this problem which can satisfy everyone's requirements
> when integrated well with spec's explain-data. I am curious to hear what
> Alex and others think about it.
>
> On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote:
>
>>
>> On Aug 24, 2016, at 9:28 PM, adrian...@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 they are intended to be helpful to someone who already
>> agrees with axioms like “good error-handling is a nail for which core.spec
>> is the hammer” and “it is wise to push the responsibility for error
>> understanding to third-party libraries or diligent study”. They do a
>> service in that they lay out the rules under which Clojure users should
>> expect to live. But they are largely reiterations rather than engagement. I
>> find that rather frustrating.
>>
>>
>> Let me point to an essential book on business/community management,
>> Hirschman’s /Exit, Voice, and Loyalty/. https://en.wikipedia
>> .org/wiki/Exit,_Voice,_and_Loyalty, and to a clever take on group
>> behavior, “Evaporative Cooling of Group Beliefs”, http://lesswrong.com
>> /lw/lr/evaporative_cooling_of_group_beliefs/. I think there is much to
>> learn from reflecting on those and the direction of Clojure design and the
>> Clojure community over the past few years. (I’m not a huge fan of the
>> application of Satir’s family counseling theory to software management -
>> Gerald Weinberg and the like - but it’s hard not to read books like the
>> /Quality Software Management/ series and see people in the Clojure
>> community - including me! - playing out stereotypical dysfunctional roles.)
>>
>> Read me as someone who’s publicly and self-destructively giving up on
>> Voice and is on the way to Exit. As someone who tends to Loyalty (though
>> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s
>> rather agonizing. That is, I still think Clojure is the best raw language
>> out there for broad-spectrum work. However, its design has been doubling
>> down on long-unfortunate tendencies, and - I’d argue - new languages like
>> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community
>> management and “peripheral” concerns like 

[ANN] clojure.java.jdbc 0.6.2 Alpha 3

[Sean Corfield]

What?
  Contrib library providing JDBC access to databases

Changes?
  https://github.com/clojure/java.jdbc#change-log
Bug fix for :qualifier / :identifiers interaction (thank you Nicola 
Momettto for finding that)
  Improved driver aliases (bug fix for PostgeSQL; new aliases for several 
others)

Roadmap?
0.6.2 introduces (optional) clojure.spec coverage for 
clojure.java.jdbc; currently a work-in-progress

Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)




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

[Stuart Halloway]

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 "convention"-type topics
you allude to. You can contribute here:
https://github.com/clojure/clojure-site.  And now also here:
https://github.com/clojure/clojurescript-site.

Stu

On Thu, Aug 25, 2016 at 11:54 AM, Gary Trakhman 
wrote:

> 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 seriously
> considered clojure (and hiring me recently under that premise), and I'm
> having to apologize for the general lack of novice guardrails,
> 'conventions' and documentation that people from other communities expect.
> I think it looks pretty good if you're used to java (java conservatism
> notwithstanding), but not so good if you've been in dynlangs (particularly
> ruby) or other FP languages besides lisp.
>
> I'm concerned the current approach will lead to too many half-baked
> error-reporters.  Alternatively, if there's a canonical human-facing
> error-reporter built on top of the more stable data representation, I think
> it would be generally acceptable to break 'contracts' there as we find
> better ways to show the errors.
>
> On Thu, Aug 25, 2016 at 11:18 AM Brian Marick 
> wrote:
>
>>
>> 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 they are intended to be helpful to someone who already
>> agrees with axioms like “good error-handling is a nail for which core.spec
>> is the hammer” and “it is wise to push the responsibility for error
>> understanding to third-party libraries or diligent study”. They do a
>> service in that they lay out the rules under which Clojure users should
>> expect to live. But they are largely reiterations rather than engagement. I
>> find that rather frustrating.
>>
>>
>> Let me point to an essential book on business/community management,
>> Hirschman’s /Exit, Voice, and Loyalty/. https://en.
>> wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and to a clever take on
>> group behavior, “Evaporative Cooling of Group Beliefs”, http://lesswrong.
>> com/lw/lr/evaporative_cooling_of_group_beliefs/. I think there is much
>> to learn from reflecting on those and the direction of Clojure design and
>> the Clojure community over the past few years. (I’m not a huge fan of the
>> application of Satir’s family counseling theory to software management -
>> Gerald Weinberg and the like - but it’s hard not to read books like the
>> /Quality Software Management/ series and see people in the Clojure
>> community - including me! - playing out stereotypical dysfunctional roles.)
>>
>> Read me as someone who’s publicly and self-destructively giving up on
>> Voice and is on the way to Exit. As someone who tends to Loyalty (though
>> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s
>> rather agonizing. That is, I still think Clojure is the best raw language
>> out there for broad-spectrum work. However, its design has been doubling
>> down on long-unfortunate tendencies, and - I’d argue - new languages like
>> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community
>> management and “peripheral” concerns like documentation and error handling.
>> In the meantime, the Clojure ideology - reinforced by memes like
>> “complecting” - has been getting more rigid.
>>
>> The result is that what seem to me bizarre decisions are treated as
>> normal. We have an `any?` in clojure.core that always returns `true`. This
>> deviance from probably every other programming language is justified as
>> obvious for a feature - clojure.spec - that is largely unproven, certainly
>> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and
>> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is
>> completely dismissed, with the justification that people complain about
>> every new name. (Think about what that decision criterion entails, broadly
>> applied.)
>>
>> Also bizarre: the idea that error messages that amount to essentially
>> dumping a parse tree + BNF-ish grammar clause (possibly twice with a
>> vomitous stack trace between) is a *good* thing. Not a “we wish we could do
>> better, but software development is about constraints and tradeoffs” thing.
>> Not a “yeah, but Rich Hickey doesn’t want to bother with 

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

[Timothy Baldridge]

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 they carry in common parlance. I can see how my choice of
wording here can be taken as a personal attack. And so for that, I do
apologize, Brian. In the future I will attempt to use less loaded verbiage.

Timothy Baldridge

On Thu, Aug 25, 2016 at 10:33 AM, Timothy Baldridge 
wrote:

> >> 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 was me. And since this seems to come up rather often I should
> probably address it. I scanned the archives and found the original
> statement I made:
> "I don't recommend Midje at all. Many of the framework's mocking
> facilities (such as providing) are abominations. You shouldn't go around
> mucking with functions and re-deffing them on the fly. It may look cute,
> but I've lost countless hours to bugs and unexpected behavior related to
> Midje. IMO, stay clear of that. "
>
> So to be clear, I called certain patterns in Midje: "abominations", not
> the library as a whole, and defiantly never you. And unfortunately I have
> to stand by characterization of these facilities. I strongly believe that
> new code evaluation semantics combined with mutation of var roots is a
> great way to add complexity to your testing suite. Changing var roots
> on-the-fly adds complexity that will come back to bite you when you add
> things like async calls and parallelism. Creating new evaluation semantics
> makes code impossible to read without fully understanding the interpreter
> of the DSL. What is executed first? What happens when? Who knows, it's a
> foreign language.
>
> But please don't take my statements as a personal attack. I have written a
> lot of bad code in my life, some of it is used daily by clojure
> programmers. I often do code reviews, and I may come across as abrasive
> when discussing a bit of ugly code, but I bear no ill-will to the
> programmer. The same applies here, I may strongly dislike aspects of Midje,
> but I can dislike someone's work without disliking them.
>
> So now I'm completely off topic for this thread, but since my statement
> back in 2014 keeps coming back time and again, I figured it was best to
> clarify my words. And Brian, if we ever are at a conference together, let's
> sit down and I'll buy us a drink (or two). It'll probably do us both good
> to get to know each other better.
>
> On Thu, Aug 25, 2016 at 9:54 AM, Gary Trakhman 
> wrote:
>
>> 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 seriously
>> considered clojure (and hiring me recently under that premise), and I'm
>> having to apologize for the general lack of novice guardrails,
>> 'conventions' and documentation that people from other communities expect.
>> I think it looks pretty good if you're used to java (java conservatism
>> notwithstanding), but not so good if you've been in dynlangs (particularly
>> ruby) or other FP languages besides lisp.
>>
>> I'm concerned the current approach will lead to too many half-baked
>> error-reporters.  Alternatively, if there's a canonical human-facing
>> error-reporter built on top of the more stable data representation, I think
>> it would be generally acceptable to break 'contracts' there as we find
>> better ways to show the errors.
>>
>> On Thu, Aug 25, 2016 at 11:18 AM Brian Marick 
>> wrote:
>>
>>>
>>> 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 they are intended to be helpful to someone who already
>>> agrees with axioms like “good error-handling is a nail for which core.spec
>>> is the hammer” and “it is wise to push the responsibility for error
>>> understanding to third-party libraries or diligent study”. They do a
>>> service in that they lay out the rules under which Clojure users should
>>> expect to live. But they are largely reiterations rather than engagement. I
>>> find that rather frustrating.
>>>
>>>
>>> Let me point to an essential book on business/community management,
>>> Hirschman’s /Exit, Voice, 

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

[Timothy Baldridge]

>> 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 was me. And since this seems to come up rather often I should
probably address it. I scanned the archives and found the original
statement I made:
"I don't recommend Midje at all. Many of the framework's mocking facilities
(such as providing) are abominations. You shouldn't go around mucking with
functions and re-deffing them on the fly. It may look cute, but I've lost
countless hours to bugs and unexpected behavior related to Midje. IMO, stay
clear of that. "

So to be clear, I called certain patterns in Midje: "abominations", not the
library as a whole, and defiantly never you. And unfortunately I have to
stand by characterization of these facilities. I strongly believe that new
code evaluation semantics combined with mutation of var roots is a great
way to add complexity to your testing suite. Changing var roots on-the-fly
adds complexity that will come back to bite you when you add things like
async calls and parallelism. Creating new evaluation semantics makes code
impossible to read without fully understanding the interpreter of the DSL.
What is executed first? What happens when? Who knows, it's a foreign
language.

But please don't take my statements as a personal attack. I have written a
lot of bad code in my life, some of it is used daily by clojure
programmers. I often do code reviews, and I may come across as abrasive
when discussing a bit of ugly code, but I bear no ill-will to the
programmer. The same applies here, I may strongly dislike aspects of Midje,
but I can dislike someone's work without disliking them.

So now I'm completely off topic for this thread, but since my statement
back in 2014 keeps coming back time and again, I figured it was best to
clarify my words. And Brian, if we ever are at a conference together, let's
sit down and I'll buy us a drink (or two). It'll probably do us both good
to get to know each other better.

On Thu, Aug 25, 2016 at 9:54 AM, Gary Trakhman 
wrote:

> 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 seriously
> considered clojure (and hiring me recently under that premise), and I'm
> having to apologize for the general lack of novice guardrails,
> 'conventions' and documentation that people from other communities expect.
> I think it looks pretty good if you're used to java (java conservatism
> notwithstanding), but not so good if you've been in dynlangs (particularly
> ruby) or other FP languages besides lisp.
>
> I'm concerned the current approach will lead to too many half-baked
> error-reporters.  Alternatively, if there's a canonical human-facing
> error-reporter built on top of the more stable data representation, I think
> it would be generally acceptable to break 'contracts' there as we find
> better ways to show the errors.
>
> On Thu, Aug 25, 2016 at 11:18 AM Brian Marick 
> wrote:
>
>>
>> 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 they are intended to be helpful to someone who already
>> agrees with axioms like “good error-handling is a nail for which core.spec
>> is the hammer” and “it is wise to push the responsibility for error
>> understanding to third-party libraries or diligent study”. They do a
>> service in that they lay out the rules under which Clojure users should
>> expect to live. But they are largely reiterations rather than engagement. I
>> find that rather frustrating.
>>
>>
>> Let me point to an essential book on business/community management,
>> Hirschman’s /Exit, Voice, and Loyalty/. https://en.
>> wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and to a clever take on
>> group behavior, “Evaporative Cooling of Group Beliefs”, http://lesswrong.
>> com/lw/lr/evaporative_cooling_of_group_beliefs/. I think there is much
>> to learn from reflecting on those and the direction of Clojure design and
>> the Clojure community over the past few years. (I’m not a huge fan of the
>> application of Satir’s family counseling theory to software management -
>> Gerald Weinberg and the like - but it’s hard not to read books like the
>> /Quality Software Management/ series and see people in the Clojure
>> community - including me! - playing out stereotypical dysfunctional roles.)
>>
>> Read me as 

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

[Gary Trakhman]

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 seriously
considered clojure (and hiring me recently under that premise), and I'm
having to apologize for the general lack of novice guardrails,
'conventions' and documentation that people from other communities expect.
I think it looks pretty good if you're used to java (java conservatism
notwithstanding), but not so good if you've been in dynlangs (particularly
ruby) or other FP languages besides lisp.

I'm concerned the current approach will lead to too many half-baked
error-reporters.  Alternatively, if there's a canonical human-facing
error-reporter built on top of the more stable data representation, I think
it would be generally acceptable to break 'contracts' there as we find
better ways to show the errors.

On Thu, Aug 25, 2016 at 11:18 AM Brian Marick 
wrote:

>
> 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 they are intended to be helpful to someone who already
> agrees with axioms like “good error-handling is a nail for which core.spec
> is the hammer” and “it is wise to push the responsibility for error
> understanding to third-party libraries or diligent study”. They do a
> service in that they lay out the rules under which Clojure users should
> expect to live. But they are largely reiterations rather than engagement. I
> find that rather frustrating.
>
>
> Let me point to an essential book on business/community management,
> Hirschman’s /Exit, Voice, and Loyalty/.
> https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and to a clever
> take on group behavior, “Evaporative Cooling of Group Beliefs”,
> http://lesswrong.com/lw/lr/evaporative_cooling_of_group_beliefs/. I think
> there is much to learn from reflecting on those and the direction of
> Clojure design and the Clojure community over the past few years. (I’m not
> a huge fan of the application of Satir’s family counseling theory to
> software management - Gerald Weinberg and the like - but it’s hard not to
> read books like the /Quality Software Management/ series and see people in
> the Clojure community - including me! - playing out stereotypical
> dysfunctional roles.)
>
> Read me as someone who’s publicly and self-destructively giving up on
> Voice and is on the way to Exit. As someone who tends to Loyalty (though
> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s
> rather agonizing. That is, I still think Clojure is the best raw language
> out there for broad-spectrum work. However, its design has been doubling
> down on long-unfortunate tendencies, and - I’d argue - new languages like
> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community
> management and “peripheral” concerns like documentation and error handling.
> In the meantime, the Clojure ideology - reinforced by memes like
> “complecting” - has been getting more rigid.
>
> The result is that what seem to me bizarre decisions are treated as
> normal. We have an `any?` in clojure.core that always returns `true`. This
> deviance from probably every other programming language is justified as
> obvious for a feature - clojure.spec - that is largely unproven, certainly
> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and
> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is
> completely dismissed, with the justification that people complain about
> every new name. (Think about what that decision criterion entails, broadly
> applied.)
>
> Also bizarre: the idea that error messages that amount to essentially
> dumping a parse tree + BNF-ish grammar clause (possibly twice with a
> vomitous stack trace between) is a *good* thing. Not a “we wish we could do
> better, but software development is about constraints and tradeoffs” thing.
> Not a “yeah, but Rich Hickey doesn’t want to bother with that stuff” thing.
>
> (I was honestly flummoxed that, although clojure.spec is supposed to be
> the answer for error handling, there’s been no attempt to work through what
> good error messages would be like and how the current infrastructure would
> support the translation from raw data to such error messages.)
>
> I cannot help but think of this as groupthink. And - to be grandiose -
> having people like me Exit will increase that, per evaporative cooling.
>
>
> 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 

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

[Alex Miller]

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 look at anything you have to say at 
> this point as anything less than trolling? 
>
> Back on topic, I find Colin's suggestions about implementing an error 
> reporting heuristic intriguing. What he has laid out could form the basis 
> for a solution to this problem which can satisfy everyone's requirements 
> when integrated well with spec's explain-data. I am curious to hear what 
> Alex and others think about it. 
>

Working on many things and may make use of the idea.

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

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 and priorities are different), I do think it will be better than it 
is now and vastly better than before spec existed.

I do not think you are a "hated Other". I welcome your contributions to the 
community. As a moderator of this list, I do not recall seeing the 
"abomination" comment on the mailing list, but I agree that that is 
inappropriate and unwelcome here. Disagreement is fine, disrespect is not. 
I regularly address comments like this either privately or publicly 
(depending on the situation) and I'm sorry I missed that one, so I 
apologize for that.

On Thursday, August 25, 2016 at 10:18:28 AM UTC-5, Brian Marick wrote:
>
>
> 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 they are intended to be helpful to someone who already 
> agrees with axioms like “good error-handling is a nail for which core.spec 
> is the hammer” and “it is wise to push the responsibility for error 
> understanding to third-party libraries or diligent study”. They do a 
> service in that they lay out the rules under which Clojure users should 
> expect to live. But they are largely reiterations rather than engagement. I 
> find that rather frustrating.
>
>
> Let me point to an essential book on business/community management, 
> Hirschman’s /Exit, Voice, and Loyalty/. 
> https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and to a clever 
> take on group behavior, “Evaporative Cooling of Group Beliefs”, 
> http://lesswrong.com/lw/lr/evaporative_cooling_of_group_beliefs/. I think 
> there is much to learn from reflecting on those and the direction of 
> Clojure design and the Clojure community over the past few years. (I’m not 
> a huge fan of the application of Satir’s family counseling theory to 
> software management - Gerald Weinberg and the like - but it’s hard not to 
> read books like the /Quality Software Management/ series and see people in 
> the Clojure community - including me! - playing out stereotypical 
> dysfunctional roles.) 
>
> Read me as someone who’s publicly and self-destructively giving up on 
> Voice and is on the way to Exit. As someone who tends to Loyalty (though 
> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s 
> rather agonizing. That is, I still think Clojure is the best raw language 
> out there for broad-spectrum work. However, its design has been doubling 
> down on long-unfortunate tendencies, and - I’d argue - new languages like 
> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community 
> management and “peripheral” concerns like documentation and error handling. 
> In the meantime, the Clojure ideology - reinforced by memes like 
> “complecting” - has been getting more rigid. 
>
> The result is that what seem to me bizarre decisions are treated as 
> normal. We have an `any?` in clojure.core that always returns `true`. This 
> deviance from probably every other programming language is justified as 
> obvious for a feature - clojure.spec - that is largely unproven, certainly 
> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and 
> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is 
> completely dismissed, with the justification that people complain about 
> every new name. (Think about what that decision criterion entails, broadly 
> applied.)
>
> Also bizarre: the idea that error messages that amount to essentially 
> dumping a parse tree + BNF-ish grammar clause (possibly twice with a 
> vomitous stack trace between) is a *good* thing. Not a “we wish we could do 
> better, but software development is about constraints and tradeoffs” thing. 
> Not a “yeah, but Rich Hickey doesn’t want to bother with that stuff” thing. 
>
> (I was honestly flummoxed that, although clojure.spec is supposed to be 
> the answer for error handling, there’s been no attempt to work through what 
> good error messages would be like and how the current infrastructure would 
> support the translation from raw data to such error messages.)
>
> I cannot help but think of this as groupthink. And - to be grandiose - 
> having people like me Exit will increase that, per evaporative cooling. 
>
>
> 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.

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

[adrian . medina]

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 topic, I find Colin's suggestions about implementing an error 
reporting heuristic intriguing. What he has laid out could form the basis 
for a solution to this problem which can satisfy everyone's requirements 
when integrated well with spec's explain-data. I am curious to hear what 
Alex and others think about it. 

On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote:
>
>
> On Aug 24, 2016, at 9:28 PM, adrian...@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 they are intended to be helpful to someone who already 
> agrees with axioms like “good error-handling is a nail for which core.spec 
> is the hammer” and “it is wise to push the responsibility for error 
> understanding to third-party libraries or diligent study”. They do a 
> service in that they lay out the rules under which Clojure users should 
> expect to live. But they are largely reiterations rather than engagement. I 
> find that rather frustrating.
>
>
> Let me point to an essential book on business/community management, 
> Hirschman’s /Exit, Voice, and Loyalty/. 
> https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty, and to a clever 
> take on group behavior, “Evaporative Cooling of Group Beliefs”, 
> http://lesswrong.com/lw/lr/evaporative_cooling_of_group_beliefs/. I think 
> there is much to learn from reflecting on those and the direction of 
> Clojure design and the Clojure community over the past few years. (I’m not 
> a huge fan of the application of Satir’s family counseling theory to 
> software management - Gerald Weinberg and the like - but it’s hard not to 
> read books like the /Quality Software Management/ series and see people in 
> the Clojure community - including me! - playing out stereotypical 
> dysfunctional roles.) 
>
> Read me as someone who’s publicly and self-destructively giving up on 
> Voice and is on the way to Exit. As someone who tends to Loyalty (though 
> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s 
> rather agonizing. That is, I still think Clojure is the best raw language 
> out there for broad-spectrum work. However, its design has been doubling 
> down on long-unfortunate tendencies, and - I’d argue - new languages like 
> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community 
> management and “peripheral” concerns like documentation and error handling. 
> In the meantime, the Clojure ideology - reinforced by memes like 
> “complecting” - has been getting more rigid. 
>
> The result is that what seem to me bizarre decisions are treated as 
> normal. We have an `any?` in clojure.core that always returns `true`. This 
> deviance from probably every other programming language is justified as 
> obvious for a feature - clojure.spec - that is largely unproven, certainly 
> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and 
> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is 
> completely dismissed, with the justification that people complain about 
> every new name. (Think about what that decision criterion entails, broadly 
> applied.)
>
> Also bizarre: the idea that error messages that amount to essentially 
> dumping a parse tree + BNF-ish grammar clause (possibly twice with a 
> vomitous stack trace between) is a *good* thing. Not a “we wish we could do 
> better, but software development is about constraints and tradeoffs” thing. 
> Not a “yeah, but Rich Hickey doesn’t want to bother with that stuff” thing. 
>
> (I was honestly flummoxed that, although clojure.spec is supposed to be 
> the answer for error handling, there’s been no attempt to work through what 
> good error messages would be like and how the current infrastructure would 
> support the translation from raw data to such error messages.)
>
> I cannot help but think of this as groupthink. And - to be grandiose - 
> having people like me Exit will increase that, per evaporative cooling. 
>
>
> 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.
>
> ---
>
> (*) Might that not be my fiendish plan? Perhaps I’m being abrasive on this 
> list exactly to associate ideas like “error messages are the responsibility 
> of the compiler” as being from a hated Other, thus hardening a position 
> that I 

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

[Brian Marick]

> 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 they are intended to be helpful to someone who already agrees 
with axioms like “good error-handling is a nail for which core.spec is the 
hammer” and “it is wise to push the responsibility for error understanding to 
third-party libraries or diligent study”. They do a service in that they lay 
out the rules under which Clojure users should expect to live. But they are 
largely reiterations rather than engagement. I find that rather frustrating.


Let me point to an essential book on business/community management, Hirschman’s 
/Exit, Voice, and Loyalty/. 
https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty 
, and to a clever take 
on group behavior, “Evaporative Cooling of Group Beliefs”, 
http://lesswrong.com/lw/lr/evaporative_cooling_of_group_beliefs/ 
. I think 
there is much to learn from reflecting on those and the direction of Clojure 
design and the Clojure community over the past few years. (I’m not a huge fan 
of the application of Satir’s family counseling theory to software management - 
Gerald Weinberg and the like - but it’s hard not to read books like the 
/Quality Software Management/ series and see people in the Clojure community - 
including me! - playing out stereotypical dysfunctional roles.) 

Read me as someone who’s publicly and self-destructively giving up on Voice and 
is on the way to Exit. As someone who tends to Loyalty (though perhaps the 
loyalty of the traditional Catholic Devil’s Advocate), it’s rather agonizing. 
That is, I still think Clojure is the best raw language out there for 
broad-spectrum work. However, its design has been doubling down on 
long-unfortunate tendencies, and - I’d argue - new languages like Rust, Elixir, 
and Elm (even Pony) - are raising the bar for both community management and 
“peripheral” concerns like documentation and error handling. In the meantime, 
the Clojure ideology - reinforced by memes like “complecting” - has been 
getting more rigid. 

The result is that what seem to me bizarre decisions are treated as normal. We 
have an `any?` in clojure.core that always returns `true`. This deviance from 
probably every other programming language is justified as obvious for a feature 
- clojure.spec - that is largely unproven, certainly when it comes to error 
reporting. (Even worse, we have `any?`, `some?`, and `some` - all 
idiosyncratic.) Yet the idea of changing the name of `any?` is completely 
dismissed, with the justification that people complain about every new name. 
(Think about what that decision criterion entails, broadly applied.)

Also bizarre: the idea that error messages that amount to essentially dumping a 
parse tree + BNF-ish grammar clause (possibly twice with a vomitous stack trace 
between) is a *good* thing. Not a “we wish we could do better, but software 
development is about constraints and tradeoffs” thing. Not a “yeah, but Rich 
Hickey doesn’t want to bother with that stuff” thing. 

(I was honestly flummoxed that, although clojure.spec is supposed to be the 
answer for error handling, there’s been no attempt to work through what good 
error messages would be like and how the current infrastructure would support 
the translation from raw data to such error messages.)

I cannot help but think of this as groupthink. And - to be grandiose - having 
people like me Exit will increase that, per evaporative cooling. 


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.

---

(*) Might that not be my fiendish plan? Perhaps I’m being abrasive on this list 
exactly to associate ideas like “error messages are the responsibility of the 
compiler” as being from a hated Other, thus hardening a position that I think 
is bad for Clojure. Why would I do that? Because I’m 90% likely to be going 
all-in on Elixir and Elm. Encouraging destructive behavior in a competitor 
language increases my languages' chances of success. Bwahaha! (Oops, just 
violated rules 6 and 7 of http://www.eviloverlord.com/lists/overlord.html 
 )

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

Re: [ANN] Leiningen 2.7.0

[Rick Moynihan]

Many, many thanks for this release!

Also the manged-dependencies feature looks like it might be super useful.

R.

On 25 August 2016 at 01:03, Jean Niklas L'orange 
wrote:

> Greetings, fellow Clojurians!
>
> I am happy to announce Leiningen 2.7.0! This release contains mostly
> bugfixes, but two major new improvements were added. There is now a
> PowerShell version of `lein.bat`, and `:managed-dependencies` has been
> added to Leiningen.
>
> Both improvements should be considered to be in beta, but please try
> them out and report bugs you find in the GitHub issue tracker. The
> rationale for `:managed-dependencies` can be found at [1].
>
> To replace `lein.bat` with the PowerShell equivalent, download
> `lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If
> you end up with an error related to `Invoke-WebRequest`, then it may
> be a result of an old version of PowerShell, which seems to be
> resolved by installing the Windows Management Framework 4.0 [4].
>
> The full list of significant user changes:
>
> * Add PowerShell script for Windows users. (Brian Lalonde)
> * Run `:prep-tasks` before `lein test`, so generated test namespaces
>   will be tested. (Martin Reck)
> * Better error message when attempting to do `lein run` without
>   `project.clj`. (Eduardo Seabra Silva)
> * Add support for `:managed-dependencies`. (Chris Price)
> * Provide the current clojars certificate. (Toby Crawley)
> * Add `*eval-print-dup*` to evaluate forms passed to
>   `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva)
> * Update bash completions. (Zack Dever)
> * Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins)
> * Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson)
> * Catch and handle fixture errors during `lein test`. (Alex Hall)
> * Fix a bug where spaces in directory names on Windows caused crashes.
>   (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange)
> * Fix a bug where `lein search` would take forever downloading
>   clojars.org. (Paul Dorman)
> * Retain user defined private repositories when building jars,
>   uberjars and deploy. (Rick Moynihan)
> * Honor whitelist settings when `lein javac` is called via `lein jar`.
>   (Chris Price)
> * `lein vsc push` for git will now only push branch-related tags.
>   (Łukasz Klich)
>
> Those who have manually installed Leiningen can run `lein upgrade` to
> pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the
> previous version if you run into any issues. Keep in mind that the
> PowerShell script was introduced in this release, hence there are no
> downgrade candidates for it right now.
>
> We have had lots of contributors help out making this release happen,
> and I'd especially like to thank Chris Price (cprice404) and Florian
> Anderiasch (winks) for their help with this release.
>
> [1]: https://github.com/technomancy/leiningen/blob/
> stable/doc/MANAGED_DEPS.md
> [2]: https://raw.githubusercontent.com/technomancy/leiningen/
> stable/bin/lein.cmd
> [3]: https://raw.githubusercontent.com/technomancy/leiningen/
> stable/bin/lein.ps1
> [4]: http://social.technet.microsoft.com/wiki/contents/
> articles/21016.how-to-install-windows-powershell-4-0.aspx
>
> -- Jean Niklas
>
>
> --
> 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.