[ANN] Clojure 1.10.0-alpha7

[Stuart Halloway]

deps.edn dependency:

  org.clojure/clojure {:mvn/version "1.10.0-alpha7"}

1.10.0-alpha7 includes the following changes since 1.10.0-alpha6:

• Update deps to latest spec.alpha (0.2.176) and core.specs.alpha (0.2.44)
  
• CLJ-2373 - categorize and overhaul printing of exception messages at REPL
  
• CLJ-1279 - report correct arity count for function arity errors inside macros
  
• CLJ-2386 - omit ex-info construction stack frames
  
• CLJ-2394 - warn in pst that stack trace for syntax error failed before execution
  
• CLJ-2396 - omit :in clauses when printing spec function errors if using default explain printer
  

[Erik Assum]

Would it be an idea to include something like 

```

clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-alpha7"}}}}’

```

in such announcements so the lazy of us could just copy/paste it into our shells to try it out?

Erik.

On 5 Sep 2018, at 14:39, Stuart Halloway <stuart....@gmail.com> wrote:

org.clojure/clojure {:mvn/version "1.10.0-alpha7"}

[Peter Hull]

On Wednesday, 5 September 2018 13:39:36 UTC+1, stuart....@gmail.com wrote:

1.10.0-alpha7 includes the following changes since 1.10.0-alpha6:

I was pleased to see that going from alpha 6 to 7 found an error in one of my tests. I had something like

(is (= (x (func y))))

and the new version reports

 error: java.lang.Exception: = expects more than one argument

But (purely for my own interest) I tried to discover which change in clojure source made the difference and I couldn't.

[Stuart Halloway]

Hi Erik,

That does seem like a good idea. Thanks!

Stu

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

[Andy Fingerhut]

Peter:

I do not know why you are seeing this change in behavior.  In order to see if I could determine why, I created my own unit test based on your description, but when I run my incorrectly unit test with Clojure 1.10.0-alpha6 or 1.10.0-alpha7, I get the same results -- no failures, and no "error: java.lang.Exception: = expects more than one argument" exception as you are seeing.  I am probably doing something too different from your code.

I created a tiny test repo on Github with what I tried, here: https://github.com/jafingerhut/catch-bad-unit-test

Here is the unit test I tried: https://github.com/jafingerhut/catch-bad-unit-test

where the definitions of functions x and y are simply these: https://github.com/jafingerhut/catch-bad-unit-test/blob/master/src/catchme/core.clj#L3-L7

If you have a few minutes to try out the tests in my repo to see if you get different results than I did, I'd be curious to hear if your results are different.  I'd be more curious to learn of a way to write a unit test that gives the exception you see with Clojure 1.10.0-alpha7.

Andy

[Andy Fingerhut]

Sorry, wrong link to the unit test that I tried, which should have been: https://github.com/jafingerhut/catch-bad-unit-test/blob/master/test/catchme/core_test.clj#L5-L7

[Peter Hull]

On Thursday, 6 September 2018 15:09:15 UTC+1, Andy Fingerhut wrote:

If you have a few minutes to try out the tests in my repo to see if you get different results than I did, I'd be curious to hear if your results are different.  I'd be more curious to learn of a way to write a unit test that gives the exception you see with Clojure 1.10.0-alpha7.

Thanks for your help. I think I've made a mistake somewhere. I use emacs + CIDER  and run the tests from there. With 'lein test' I don't see that error, but I do from emacs. So it may be something that's been updated in CIDER rather than clojure itself. I didn't realise they were different.

The offending test was in a work project which has been put on hold/abandoned, but every time a new clojure comes out, I test it again to check it still works (ever hopeful it might be reinstated!). So, more had changed than just alpha6 to alpha7 when I tested this time.

Does that make sense?

Peter

[Andy Fingerhut]

Thanks for the response.  Makes sense.  I haven't used CIDER before, and don't plan to try it out just to learn if it has a feature that checks unit tests for problems.  If anyone else knows whether CIDER has a feature to do that, I would be a little curious to learn more about it.

Thanks,

Andy

[Andy Fingerhut]

Doing a little bit more digging, I just did a Google search for:

clojure "expects more than one argument"

and found this code hit that may be relevant for CIDER users:

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/test/extensions.clj#L28

Andy

[Peter Hull]

On Thursday, 6 September 2018 19:11:14 UTC+1, Andy Fingerhut wrote:

Doing a little bit more digging, I just did a Google search for:

clojure "expects more than one argument"

Nice one, thanks. I did a similar search but didn't find that - instead a repo called "venantius/ultra" which has the same text in, which I assumed must be a dependency of cider somehow.

[Matching Socks]

A linter is a good place for a warning that = is used with one apparent argument.  Eastwood to the rescue!

src/easter/core.clj:6:3: suspicious-expression: = called with 1 args.  (= x) always returns true.  Perhaps there are misplaced parentheses?

Since = (and also < and > ) are handy in conjunction with apply to compute the consistency of a whole list of things, it's nice that they tolerate getting 1 argument.  I suppose that is their degenerate case.

[Sean Corfield]

Thank you! We’ve been testing against master-SNAPSHOT all along but we’ve decided we’ll try to take this to production (probably next week) to give the new ASM stuff a good run.

 

(which is a bit slow for us – we normally take alphas to production pretty much as they appear 😊 )

 

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

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

---

From: clo...@googlegroups.com <clo...@googlegroups.com> on behalf of Stuart Halloway <stuart....@gmail.com>
Sent: Wednesday, September 5, 2018 5:39:16 AM
To: clo...@googlegroups.com
Subject: [ANN] Clojure 1.10.0-alpha7

 

[Mamun]

After update to version "1.10.0-alpha7", I found pedestal/log is broken

pedestal version 0.5.4.

Here is details info in bellow

(ns io.pedestal.log

"Logging via slf4j. Each logging level is a macro: trace, debug,

info, warn, and error. Each namespace gets its own Logger. Arguments

are key-value pairs, which will be printed as with 'pr'. The special

key :exception should have a java.lang.Throwable as its value, and

will be passed separately to the underlying logging API.

One can override the logger via JVM or ENVAR settings."

(:require clojure.string)

(:import (org.slf4j Logger

LoggerFactory

MDC)

(org.slf4j.spi MDCAdapter)

(com.codahale.metrics MetricRegistry

Gauge Counter Histogram Meter

Slf4jReporter)

(com.codahale.metrics.jmx JmxReporter)

(io.opentracing Scope

Span

SpanContext

Tracer

Tracer$SpanBuilder)

(io.opentracing.log.Fields)

(io.opentracing.util GlobalTracer)

(java.util Map)

(java.util.concurrent TimeUnit)

(clojure.lang IFn)))

Error msg

Syntax error macroexpanding clojure.core/ns at (io/pedestal/log.clj:13:1). Cause: Call to clojure.core/ns did not conform to spec.
() - failed: Insufficient input at: [:ns-clauses :import :classes :package-list :classes] spec: :clojure.core.specs.alpha/package-list
(io.opentracing.log.Fields) - failed: simple-symbol? at: [:ns-clauses :import :classes :class] spec: :clojure.core.specs.alpha/ns-import
:import - failed: #{:refer-clojure} at: [:ns-clauses :refer-clojure :clause] spec: :clojure.core.specs.alpha/ns-refer-clojure
:import - failed: #{:require} at: [:ns-clauses :require :clause] spec: :clojure.core.specs.alpha/ns-require
:import - failed: #{:use} at: [:ns-clauses :use :clause] spec: :clojure.core.specs.alpha/ns-use
:import - failed: #{:refer} at: [:ns-clauses :refer :clause] spec: :clojure.core.specs.alpha/ns-refer
:import - failed: #{:load} at: [:ns-clauses :load :clause] spec: :clojure.core.specs.alpha/ns-load
:import - failed: #{:gen-class} at: [:ns-clauses :gen-class :clause] spec: :clojure.core.specs.alpha/ns-gen-class

Br,

Mamun

[Alex Miller]

Hi Mamun, this was already broken but the spec on ns import clauses was tightened to be able to discover it.

In particular, this:

(io.opentracing.log.Fields)   is invalid - it should be:   (io.opentracing.log Fields) That was silently doing nothing before (it was not being imported) but now is erroring. I'll try to poke the right people to get pedestal updated.

[Alex Miller]

PR'ed here:

https://github.com/pedestal/pedestal/pull/591

For now, you could peg to the prior version of org.clojure/core.specs.alpha dep, version 0.2.36, to avoid this.